• Benji Smith (30/30) Mar 07 2005 I gotta say, I strongly strongly strongly dislike the current proposal
• xs0 (10/53) Mar 07 2005 I fully agree and again express support for $length, $args and the rest
• Walter (2/2) Mar 07 2005 One note on 'length' - it makes it easy for a class to have array semant...
• xs0 (4/8) Mar 07 2005 Yup, but isn't length an issue only inside [], because it introduces a
• Walter (2/4) Mar 07 2005 Yup.
• xs0 (5/5) Mar 07 2005 Hmm, now that I think about it, it would be neat to have $ call length()...
• Walter (2/7) Mar 07 2005
• xs0 (9/16) Mar 08 2005 Well, it's your call, but I think it would fit the
• Derek Parnell (13/56) Mar 07 2005 Well said and well argued. When I sit down and think about it, my only
• Matthew (6/34) Mar 08 2005 Largely agree. I'm now off the idea of $ as a standalone 'keyword', but ...

Benji Smith <dlanguage xxagg.com> writes:

I gotta say, I strongly strongly strongly dislike the current proposal

represent the length of an array.

I don't like it at all.

In my opinion, there needs to be some consistency in the use of
keywords and symbols to convey both the syntax and semantics of the
language.

Up until now, that usage has been pretty consistent. Symbolic
characters have (so far) been used exclusively as operators. Whenever
the language has needed a way to express properties, it has used
keywords.

The separation is nice...

symbols --> syntax
keywords --> semantics

The use of a single symbolic character in a semantic context, to
denote the "length" property is undesirable not because it's "ugly" or
because it "looks like perl" but because it violates the existing
conventions of syntactical and semantic expression in the language.

To me, a proposal like this seems like a knee-jerk reaction to a small
problem (collision with some existing variable names) rather than
reflecting a well-thought-out design.


for properties, I might support that kind of syntax...

      int[] slice = full_array[x .. ^length];

...but I really really really dislike the inconsistency introduced
into the language if we start using symbol characters as shortcuts for
properties.

And that's all I've got to say.

Thaks,

--Benji Smith

xs0 <xs0 xs0.com> writes:

I fully agree and again express support for $length, $args and the rest 
of the bunch.

I feel that $ is most appropriate because (in random order)
- it's most similar to a letter and looks best (at least to me)
- it is used in other languages for variables (Java, PHP, Perl), so is
   still potentially familiar
- is not legal in a normal identifier in D, so it shows that $vars
   are 'special'


xs0


Benji Smith wrote:
 I gotta say, I strongly strongly strongly dislike the current proposal

 represent the length of an array.
 
 I don't like it at all.
 
 In my opinion, there needs to be some consistency in the use of
 keywords and symbols to convey both the syntax and semantics of the
 language.
 
 Up until now, that usage has been pretty consistent. Symbolic
 characters have (so far) been used exclusively as operators. Whenever
 the language has needed a way to express properties, it has used
 keywords.
 
 The separation is nice...
 
 symbols --> syntax
 keywords --> semantics
 
 The use of a single symbolic character in a semantic context, to
 denote the "length" property is undesirable not because it's "ugly" or
 because it "looks like perl" but because it violates the existing
 conventions of syntactical and semantic expression in the language.
 
 To me, a proposal like this seems like a knee-jerk reaction to a small
 problem (collision with some existing variable names) rather than
 reflecting a well-thought-out design.
 

 for properties, I might support that kind of syntax...
 
       int[] slice = full_array[x .. ^length];
 
 ....but I really really really dislike the inconsistency introduced
 into the language if we start using symbol characters as shortcuts for
 properties.
 
 And that's all I've got to say.
 
 Thaks,
 
 --Benji Smith

"Walter" <newshound digitalmars.com> writes:

One note on 'length' - it makes it easy for a class to have array semantics,
as the 'length' will be looked up as a property of the class instance.

xs0 <xs0 xs0.com> writes:

Yup, but isn't length an issue only inside [], because it introduces a 
new scope and overrides other variables called 'length'?


xs0


Walter wrote:
 One note on 'length' - it makes it easy for a class to have array semantics,
 as the 'length' will be looked up as a property of the class instance.
 
 

"Walter" <newshound digitalmars.com> writes:

"xs0" <xs0 xs0.com> wrote in message news:d0iq5j$mev$2 digitaldaemon.com...
 Yup, but isn't length an issue only inside [], because it introduces a
 new scope and overrides other variables called 'length'?

Yup.

xs0 <xs0 xs0.com> writes:

Hmm, now that I think about it, it would be neat to have $ call length() 
on classes?

I still hope you'll change $ to $len or $length.. $&1?2:3 just doesn't 
look very nice to me :)


xs0

"Walter" <newshound digitalmars.com> writes:

"xs0" <xs0 xs0.com> wrote in message news:d0iv7h$rqf$1 digitaldaemon.com...
 Hmm, now that I think about it, it would be neat to have $ call length()
 on classes?

It could, it's just more junk in the compiler :-(

 I still hope you'll change $ to $len or $length.. $&1?2:3 just doesn't
 look very nice to me :)


 xs0

xs0 <xs0 xs0.com> writes:

Well, it's your call, but I think it would fit the 
classes-can-have-array-semantics strategy.. otoh, I guess it's not that 
important (as in, it is not strictly necessary, because one can always 
use obj.length).. it would allow use of $ in templates (that can accept 
either arrays or array-like objects), though..

Anyway, if it takes 5 minutes (for you to implement it), I guess it's 
worth it, if it takes 2 hours, I guess it's not (at least at this time).


xs0


Walter wrote:
 "xs0" <xs0 xs0.com> wrote in message news:d0iv7h$rqf$1 digitaldaemon.com...
 
Hmm, now that I think about it, it would be neat to have $ call length()
on classes?

 
 
 It could, it's just more junk in the compiler :-(

Derek Parnell <derek psych.ward> writes:

On Mon, 07 Mar 2005 16:28:07 -0700, Benji Smith wrote:

 I gotta say, I strongly strongly strongly dislike the current proposal

 represent the length of an array.
 
 I don't like it at all.
 
 In my opinion, there needs to be some consistency in the use of
 keywords and symbols to convey both the syntax and semantics of the
 language.
 
 Up until now, that usage has been pretty consistent. Symbolic
 characters have (so far) been used exclusively as operators. Whenever
 the language has needed a way to express properties, it has used
 keywords.
 
 The separation is nice...
 
 symbols --> syntax
 keywords --> semantics
 
 The use of a single symbolic character in a semantic context, to
 denote the "length" property is undesirable not because it's "ugly" or
 because it "looks like perl" but because it violates the existing
 conventions of syntactical and semantic expression in the language.
 
 To me, a proposal like this seems like a knee-jerk reaction to a small
 problem (collision with some existing variable names) rather than
 reflecting a well-thought-out design.
 

 for properties, I might support that kind of syntax...
 
       int[] slice = full_array[x .. ^length];
 
 ...but I really really really dislike the inconsistency introduced
 into the language if we start using symbol characters as shortcuts for
 properties.
 
 And that's all I've got to say.
 
 Thaks,
 
 --Benji Smith

Well said and well argued. When I sit down and think about it, my only
criteria are that it be short, legible, meaningful, and doesn't clash with
any identifiers. So I'd back something like $len, #len, ^len, or  len. But
I guess $length, et al would also suffice.

    result_array[$len] = full_array[$len - var .. index_array[$len]] 

to me is tidier than 

    result_array[result_array.length] = full_array[full_array.length - var
                   .. index_array[index_array.length]] 

-- 
Derek
Melbourne, Australia
8/03/2005 10:40:12 AM

"Matthew" <admin.hat stlsoft.dot.org> writes:

"Benji Smith" <dlanguage xxagg.com> wrote in message
news:21op21541aju6v0j4b8giivhdfv6g9fjp4 4ax.com...
I gotta say, I strongly strongly strongly dislike the current proposal

 represent the length of an array.

 I don't like it at all.

 In my opinion, there needs to be some consistency in the use of
 keywords and symbols to convey both the syntax and semantics of the
 language.

 Up until now, that usage has been pretty consistent. Symbolic
 characters have (so far) been used exclusively as operators. Whenever
 the language has needed a way to express properties, it has used
 keywords.

 The separation is nice...

 symbols --> syntax
 keywords --> semantics

 The use of a single symbolic character in a semantic context, to
 denote the "length" property is undesirable not because it's "ugly" or
 because it "looks like perl" but because it violates the existing
 conventions of syntactical and semantic expression in the language.

 To me, a proposal like this seems like a knee-jerk reaction to a small
 problem (collision with some existing variable names) rather than
 reflecting a well-thought-out design.


 for properties, I might support that kind of syntax...

      int[] slice = full_array[x .. ^length];

 ...but I really really really dislike the inconsistency introduced
 into the language if we start using symbol characters as shortcuts for
 properties.

 And that's all I've got to say.

Largely agree. I'm now off the idea of $ as a standalone 'keyword', but rather
as a local-context modifier, whatever 
that means.

For the record, I think   should be reserved for future insights by Walter.



^ is an arithmetic operator, so not suitable. (It also looks like that awful
C++.NET syntax.)