In article <d0nmoa$4kf$1@digitaldaemon.com>, Jarrett Billingsley says...
>
>> I think the use of '$' can be traced back to regular expressions,
>
>Of course, to someone who has no idea what regex syntax even is, it just seems stupid.  Especially coming from a BASIC background, in which $ is the "string variable" suffix.
>
>> It *does* take some getting used to though.
>
>I really hate how length has been deprecated.  I really don't like the $ one bit.

Hold onto your shorts, Jarrett! Walter is apparently trying to make the development process more transparent, and this is one way in which (it was suggested) to make this happen. We should support him in doing this, rather than miscontrue it.

If you look at the changelog, it effectively describes this as a "test". It's good that Walter get's feedback on your preferences, but nothing has been deprecated at this time :-)

Having said that, I'd have to agree with you. Let's hope that general opinion converges on some means of collecting the various 'meta-tags' into a recognizable form, whilst still being reasonably explicit?

While also agreeing with what Ben noted (regarding the vague PP association), I think it would be good to see @length, @argptr, @arguments, and so on (or $length, $argptr, $arguments). Firstly; there's no chance of a user-name clash, since those symbols are not valid in user-identifiers. Second; it open the door to further meta-tags without having to worry about additional reserved words. Third; in a nod to Ben, they /are/ easily identifiable from the rest of the source. This could be viewed as a really good thing, rather than a negative.

As Matthew pointed out, there's perhaps some subtle 'overloading' going on when one applies the same notion to @file, @line, @timestamp etc (or $file, $line, $timestamp), since these latter meta-tags are kinda' static whereas the former items are not. I'm not convinced that's really a problem though ~ don't we kinda' use apply conventions to static and non-static members of a class?

Regardless, it would behoove D to support point one and two above.

- Kris

In article <d0npv9$8ia$1@digitaldaemon.com>, Kris says...
>As Matthew pointed out, there's perhaps some subtle 'overloading' going on when one applies the same notion to @file, @line, @timestamp etc (or $file, $line, $timestamp), since these latter meta-tags are kinda' static whereas the former items are not. I'm not convinced that's really a problem though ~ don't we kinda' use apply conventions to static and non-static members of a class?

Ack! Wish we could edit posts on this NG;

That last question should have read "don't we kinda' apply similar conventions to static and non-static class members?"

In article <op.sndzksf7nxgd8b@umalgas>, Derek Parnell says...
>
>Ummm...no it is working exactly as if you had have typed "sTest.length" instead of "$".
>
>You have to remember the weird way that slice references work. Namely that a slice of [X .. Y] selects all the elements from X up to but not including Y. And that references are zero-based. Thus array[array.length] always references the non-existant element just after the last one. And array[0 .. array.length] references element 0 through to, but not including, the non-existant one just beyond the end.
>
>Weird I know, but Walter has chosen.
>
>
>-- 
>Derek

Opps! Thanks for the reminder, I've been using slices for almost a year now. Guess I got a brain-freeze when looking at the funny syntax "$" instead of the normal array.length. :)

It's funny the things one accepts as fact after you've used them for a while, until their appearance changes...like changing array[ 0 .. length ] to array[ 0 . $ ]. Now I'm feeling a little embrassed.

David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"

Jarrett Billingsley wrote:

> I really hate how length has been deprecated. I really don't like the $ one bit. 

It's just the "magic" length variable that
has (presumably ?) been deprecated now...

And nobody will miss the disappearance of that one.
http://www.digitalmars.com/d/changelog.html#new099


the .length array property still works, and
probably still will when the others are gone... :-)

See http://www.digitalmars.com/d/arrays.html:

>  Within the [ ] of a static or a dynamic array,
> the variable length  is implicitly declared and
> set to the length of the array.
>
> 	int[4] foo;
> 	int[]  bar = foo;

> // These expressions are equivalent:
> 	bar[]
> 	bar[0 .. 4]

  	bar[0 .. length]
 	bar[0 .. $]

> 	bar[0 .. bar.length]

--anders

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:d0nmoa$4kf$1@digitaldaemon.com...
>> I think the use of '$' can be traced back to regular expressions,
>
> Of course, to someone who has no idea what regex syntax even is, it just seems stupid.

That may be so, but that's a piss poor rationale for a criticism. Were it as black and white as that, then ignorance of regex would be the thing to address. It's not exactly a useless skill to have ...

>  Especially coming from a BASIC background, in which $ is the "string
> variable" suffix.
>
>> It *does* take some getting used to though.
>
> I really hate how length has been deprecated.  I really don't like the $ one bit.

Ok, that's opinion. Gotcha. Now, how about some substantiation?

(btw, I'm now moving away from $ after having been a great supporter. And feeling a little guilty that my former enthusiasm may have helped influence Walter to go down this cul-de-sac <g>)

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d0nlai$302$1@digitaldaemon.com...
>
> "David Medlock" <amedlock@nospam.org> wrote in message news:d0niiq$31d5$1@digitaldaemon.com...
>> <snip>
>>
>> I think the $ is a bad choice.
>>
>> What does a dollar sign have to do with length of an array?
>> We use '.' and [] because C/C++ uses them.
>> What is the precedence for '$'?
>> It lowers readability and doesn't add much at all to the language.
>>
>> This similar to some choices made durings C++'s lifetime(C too! see trigraphs) which makes for cluttered code, lots of special syntaxes to rememeber, and general inconsistency.  Not this one decision, but add them all up and you get a mess.
>>
>> All my opinion, of course.
>> -David
>>
>
> I agree. Using an identifier is something people recognize and can understand. Seeing $ will confuse people and think there is more magic in there than there is.  When I see $ used for this (or even when I imagine $length, $arguments, etc) I can't relate it to any other C-like language construct that I know.

Hmm. That actually gets a big "So what?". I mean, seeing char[], aa declaration syntax, opThis and opThat, are all foreign/unfamiliar.

To me it seems not the slightest bizarre. But then I am a big fan of Ruby, which has such things by the bucketload.

> It actually looks to me like a preprocessor hook of some kind or shell-like environment variable expansion.

Is that a bad thing? I think the opposite. If we adopt this $xyz thing - i.e. we can find significant use, and it can have good unambiguous semantics - then the distinctness of it is precisely what's required.

Matthew wrote:
> "Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d0nlai$302$1@digitaldaemon.com...
> 
>>"David Medlock" <amedlock@nospam.org> wrote in message news:d0niiq$31d5$1@digitaldaemon.com...
>>
>>><snip>
>>>
>>>I think the $ is a bad choice.
>>>
>>>What does a dollar sign have to do with length of an array?
>>>We use '.' and [] because C/C++ uses them.
>>>What is the precedence for '$'?
>>>It lowers readability and doesn't add much at all to the language.
>>>
>>>This similar to some choices made durings C++'s lifetime(C too! see trigraphs) which makes for cluttered code, lots of special syntaxes to rememeber, and general inconsistency.  Not this one decision, but add them all up and you get a mess.
>>>
>>>All my opinion, of course.
>>>-David
>>>
>>
>>I agree. Using an identifier is something people recognize and can understand. Seeing $ will confuse people and think there is more magic in there than there is.  When I see $ used for this (or even when I imagine $length, $arguments, etc) I can't relate it to any other C-like language construct that I know.
> 
> 
> Hmm. That actually gets a big "So what?". I mean, seeing char[], aa declaration syntax, opThis and opThat, are all foreign/unfamiliar.
> 
> To me it seems not the slightest bizarre. But then I am a big fan of Ruby, which has such things by the bucketload.
> 

Well I am a big fan of python, so lets use the array[:] syntax.  Just because its used somewhere doesn't mean its good here.

D is derived from C and C++, so idioms from those languages make LOTS of sense, since that is whom you are targeting with the language.

OpThis and opThat are worlds better than the C++ way, more readable and easier for tools to parse.

Not trying to start an argument here, but no one has really made the 'why its better' or even 'why its needed' argument.

...

Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.
(from Revised Report on Scheme, 1991)

>> To me it seems not the slightest bizarre. But then I am a big fan of Ruby, which has such things by the bucketload.
>>
>
> Well I am a big fan of python, so lets use the array[:] syntax.  Just because its used somewhere doesn't mean its good here.
>
> D is derived from C and C++, so idioms from those languages make LOTS of sense, since that is whom you are targeting with the language.
>
> OpThis and opThat are worlds better than the C++ way, more readable and easier for tools to parse.
>
> Not trying to start an argument here, but no one has really made the 'why its better' or even 'why its needed' argument.
>
> ...
>
> Programming languages should be designed not by piling feature on top
> of feature, but by removing the weaknesses and restrictions that make
> additional features appear necessary.
> (from Revised Report on Scheme, 1991)

reaching to the converted

Matthew wrote:
>>>To me it seems not the slightest bizarre. But then I am a big fan of Ruby, which has such things by the bucketload.
>>>
>>
>>Well I am a big fan of python, so lets use the array[:] syntax.  Just because its used somewhere doesn't mean its good here.
>>
>>D is derived from C and C++, so idioms from those languages make LOTS of sense, since that is whom you are targeting with the language.
>>
>>OpThis and opThat are worlds better than the C++ way, more readable and easier for tools to parse.
>>
>>Not trying to start an argument here, but no one has really made the 'why its better' or even 'why its needed' argument.
>>
>>...
>>
>>Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.
>>(from Revised Report on Scheme, 1991)
> 
> 
> reaching to the converted
> 
I was actually reaching out to whomever used the arguments you mentioned Matthew. :)

"David Medlock" <amedlock@nospam.com> wrote in message news:d0o426$jnd$1@digitaldaemon.com...
> Matthew wrote:
>>>>To me it seems not the slightest bizarre. But then I am a big fan of Ruby, which has such things by the bucketload.
>>>>
>>>
>>>Well I am a big fan of python, so lets use the array[:] syntax.  Just because its used somewhere doesn't mean its good here.
>>>
>>>D is derived from C and C++, so idioms from those languages make LOTS of sense, since that is whom you are targeting with the language.
>>>
>>>OpThis and opThat are worlds better than the C++ way, more readable and easier for tools to parse.
>>>
>>>Not trying to start an argument here, but no one has really made the 'why its better' or even 'why its needed' argument.
>>>
>>>...
>>>
>>>Programming languages should be designed not by piling feature on top
>>>of feature, but by removing the weaknesses and restrictions that make
>>>additional features appear necessary.
>>>(from Revised Report on Scheme, 1991)
>>
>>
>> reaching to the converted
>>
> I was actually reaching out to whomever used the arguments you mentioned Matthew. :)

and now you've lost me completely.

You seem to be saying that familiarity with some languages is fine and with others it's not. That may be so, but drawing the line is always going to be an arbitrary decision. Have I missed anything beyond that?