www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - It's time to deprecate "array [length]" in favour of "array [$]"

reply Burton Radons <burton-radons smocky.com> writes:
The contextual identifier "length" has been a problem ever since it was 
introduced (I can never seem to stop naming an identifier I'm going to 
use in an array "length", and any time I use it intentionally it looks 
odd), and we've had the superior "$" for a long time now.  As a result, 
"length" is becoming even more of a problem because I forget it even 
exists, and I'm sure there are people who don't know of the superior 
alternative.  I think it's now time to go to the next step and deprecate 
and eventually remove this bad thing.
Oct 21 2005
next sibling parent reply John Demme <me teqdruid.com> writes:
Wow.  I haven't heard any discussion of this in a long time.

I second that movement.

~John Demme


On Fri, 21 Oct 2005 22:30:25 +0000, Burton Radons wrote:


 The contextual identifier "length" has been a problem ever since it was 
 introduced (I can never seem to stop naming an identifier I'm going to 
 use in an array "length", and any time I use it intentionally it looks 
 odd), and we've had the superior "$" for a long time now.  As a result, 
 "length" is becoming even more of a problem because I forget it even 
 exists, and I'm sure there are people who don't know of the superior 
 alternative.  I think it's now time to go to the next step and deprecate 
 and eventually remove this bad thing.
Oct 22 2005
parent reply Oskar Linde <olREM OVEnada.kth.se> writes:
John Demme wrote:


 Wow.  I haven't heard any discussion of this in a long time.
 
 I second that movement.
 
 ~John Demme
 
 
 On Fri, 21 Oct 2005 22:30:25 +0000, Burton Radons wrote:
 

 The contextual identifier "length" has been a problem ever since it was
 introduced (I can never seem to stop naming an identifier I'm going to
 use in an array "length", and any time I use it intentionally it looks
 odd), and we've had the superior "$" for a long time now.  As a result,
 "length" is becoming even more of a problem because I forget it even
 exists, and I'm sure there are people who don't know of the superior
 alternative.  I think it's now time to go to the next step and deprecate
 and eventually remove this bad thing.




I'm not sure I agree. I can't help finding the contextual binding of length
elegant, and I think it opens the door to making something more general.
Random snippets:

Image image = readImage();
Image upperLeftImage = image[upperLeft..center];
Image centerImage = image[center-3..center+3];

Tree tree = createTree();
doSomething(tree[left..right]);
doSomethingElse(tree[root..right]);

and why not:

char[] string = someText();
char[] args = string[indexOf('(')+1..indexOf(')')];

IMHO, $ feels artificial, and it certainly isn't as self-explanatory as
length to someone that doesn't know D. How many other attributes than
array.length have their own symbol? Or any symbol at all in any context? I
can't think of any right now... (I personally find it ugly too, but that is
a rather weak argument) :)

In the end, I would prefer $ to be depreciated. D doesn't have to become a
new Perl. A programming language should have as few and general features as
possible to become powerful. $ doesn't make the language more powerful. It
merely saves a few keystrokes.

/Oskar
Oct 22 2005
parent reply Burton Radons <burton-radons smocky.com> writes:
Oskar Linde wrote:

 John Demme wrote:
 
 

Wow.  I haven't heard any discussion of this in a long time.

I second that movement.

~John Demme


On Fri, 21 Oct 2005 22:30:25 +0000, Burton Radons wrote:



The contextual identifier "length" has been a problem ever since it was
introduced (I can never seem to stop naming an identifier I'm going to
use in an array "length", and any time I use it intentionally it looks
odd), and we've had the superior "$" for a long time now.  As a result,
"length" is becoming even more of a problem because I forget it even
exists, and I'm sure there are people who don't know of the superior
alternative.  I think it's now time to go to the next step and deprecate
and eventually remove this bad thing.




 
 
 I'm not sure I agree. I can't help finding the contextual binding of length
 elegant, and I think it opens the door to making something more general.
 Random snippets:
 
 Image image = readImage();
 Image upperLeftImage = image[upperLeft..center];
 Image centerImage = image[center-3..center+3];


That leaves code fragile to changes in the class, or even in a base 
class which you're not under control of.  No error will be reported, but 
the meaning of the code will be altered.  This problem also exists in 
member functions, of course, but everything is centralised there.

This is why I never use "with" anymore; at some point it always seems to 
produce fragile base class problems.  And I'm one person!  I can't 
imagine how problematic that would get with a team, or with multiple 
teams working together, or with a program over five years old.


 Tree tree = createTree();
 doSomething(tree[left..right]);
 doSomethingElse(tree[root..right]);
 
 and why not:
 
 char[] string = someText();
 char[] args = string[indexOf('(')+1..indexOf(')')];


And now it's fragile to what you've imported, great!  What do I do if 
there are suddenly conflicts?  Do I have to retcon what may be hundreds 
or thousands of function calls?  Can you guarantee that the sad sack 
maintainer having to do that will do it right each and every time?


 IMHO, $ feels artificial, and it certainly isn't as self-explanatory as
 length to someone that doesn't know D. How many other attributes than
 array.length have their own symbol? Or any symbol at all in any context? I
 can't think of any right now... (I personally find it ugly too, but that is
 a rather weak argument) :)


What a person learning D thinks is irrelevant, all that's important is 
what a person using D thinks.


 In the end, I would prefer $ to be depreciated. D doesn't have to become a
 new Perl. A programming language should have as few and general features as
 possible to become powerful. $ doesn't make the language more powerful. It
 merely saves a few keystrokes.


Do not put words in my mouth.  I don't prefer $ because it's shorter (I 
never use abbreviations in my function names, for example), I prefer it 
because it has one single meaning and the alternative has been a 
consistent cause of bugs over the last year.  I don't really care what 
the symbol is.  Making length an actual keyword would also be fine.

Having one additional symbol to C doesn't make a language a Perl.  Don't 
use stupid arguments.
Oct 22 2005
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <djds6t$u2$1 digitaldaemon.com>, Burton Radons says...

This is why I never use "with" anymore; at some point it always seems to 
produce fragile base class problems.  And I'm one person!  I can't 
imagine how problematic that would get with a team, or with multiple 
teams working together, or with a program over five years old.


I don't use 'with' either, for much the same reason--I don't like the ambiguity
that 'with' tends to create.  By contrast, I like the 'length' convention
because the scope it's valid in is quite small, and because I find it more
meaningful than '$'.
Oct 22 2005
prev sibling parent Oskar Linde <olREM OVEnada.kth.se> writes:
Burton Radons wrote:


 Oskar Linde wrote:

On Fri, 21 Oct 2005 22:30:25 +0000, Burton Radons wrote:



The contextual identifier "length" has been a problem ever since it was
introduced (I can never seem to stop naming an identifier I'm going to
use in an array "length", and any time I use it intentionally it looks
odd), and we've had the superior "$" for a long time now.  As a result,
"length" is becoming even more of a problem because I forget it even
exists, and I'm sure there are people who don't know of the superior
alternative.  I think it's now time to go to the next step and deprecate
and eventually remove this bad thing.




 
 
 I'm not sure I agree. I can't help finding the contextual binding of
 length elegant, and I think it opens the door to making something more
 general. Random snippets:
 
 Image image = readImage();
 Image upperLeftImage = image[upperLeft..center];
 Image centerImage = image[center-3..center+3];


 
 That leaves code fragile to changes in the class, or even in a base
 class which you're not under control of.  No error will be reported, but
 the meaning of the code will be altered.  This problem also exists in
 member functions, of course, but everything is centralised there.


Yes. I agree that this is fragile. Something that would help would be if the
compiler forbade shadowing of identifiers in those cases:

int length = 5;
char[] str = str2[0..length]; // Ambigous: use str2.length or .length

and here:

class T { int length; }
//...
int length = 5;
T t = new T;
with (t) 
  length = 2; // ambigous

There is currently a warning for the first case:
warning - Error: array 'length' hides other 'length' name in outer scope


 This is why I never use "with" anymore; at some point it always seems to
 produce fragile base class problems.  And I'm one person!  I can't
 imagine how problematic that would get with a team, or with multiple
 teams working together, or with a program over five years old.


I think the following would be a better practice than using with:

Instead of:
with(someClass) {
  someAttribute = someMemberFunction;
}

Use:
{
  alias someClass x;
  x.someAttribute = x.someMemberFunction;
}

Maybe a keyword similar to 'this' for classes, say 'current' (or even a
symbol, why not $ ;) ) could refer to the array or object in a with-scope:

getArray()[current.middle .. current.length];
 

 

 Tree tree = createTree();
 doSomething(tree[left..right]);
 doSomethingElse(tree[root..right]);
 
 and why not:
 
 char[] string = someText();
 char[] args = string[indexOf('(')+1..indexOf(')')];


 
 And now it's fragile to what you've imported, great!  


That fragility exists in every use of functions-on-arrays-becomes-methods 
(or whatever it should be named) and is not specific to this case. 


 What do I do if 
 there are suddenly conflicts?  Do I have to retcon what may be hundreds
 or thousands of function calls?  Can you guarantee that the sad sack
 maintainer having to do that will do it right each and every time?


I don't think many people will give you such a guarantee for any programming
job. :) 


 

 IMHO, $ feels artificial, and it certainly isn't as self-explanatory as
 length to someone that doesn't know D. How many other attributes than
 array.length have their own symbol? Or any symbol at all in any context?
 I can't think of any right now... (I personally find it ugly too, but
 that is a rather weak argument) :)


 
 What a person learning D thinks is irrelevant, all that's important is
 what a person using D thinks.


The world isn't divided between just two groups: people learning D and
people using D. Transparency is important for others aswell.


 

 In the end, I would prefer $ to be depreciated. D doesn't have to become
 a new Perl. A programming language should have as few and general
 features as possible to become powerful. $ doesn't make the language more
 powerful. It merely saves a few keystrokes.


 
 Do not put words in my mouth.  I don't prefer $ because it's shorter (I
 never use abbreviations in my function names, for example), I prefer it
 because it has one single meaning and the alternative has been a
 consistent cause of bugs over the last year.  I don't really care what
 the symbol is.  Making length an actual keyword would also be fine.


I wasn't trying to put words in your mouth. I apologize. I also didn't fully
realise the extent of the problem.


 Having one additional symbol to C doesn't make a language a Perl.  Don't
 use stupid arguments.


I'm not very proficient in English. I was unable to express what I wanted to
say in the first place in a better way. 

'length' is a pseudo-keyword when it appears within []. $ has the same
meaning. I fail to see a good reason to use a symbol instead of a keyword
here.

The only advantage of $ over 'length' is that it is not usable outside of
[]. None of them are as far as I know usable for user defined types.

Oh, well... You can always do:

class MyArrayContainer {
        int length() { return 4; }
        int opIndex(int i) { return i; }
}

void main() {
        MyArrayContainer arr = new MyArrayContainer;

        int __dollar = 7;
        writef("%d ",arr[$-1]);
        arr[$=15];
        writef("%d\n",arr[++$]);
}

prints 6 16

:)

It would be useful if length and $ bound to the actual length property of
the object... The following compiles:

int[] x;
x[$++] = 0;
x[($ = $+1)-1] = 0;

(But gives ArrayBoundsError)

Regards

/Oskar
Oct 23 2005
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <djcipj$ilp$1 digitaldaemon.com>, Burton Radons says...

The contextual identifier "length" has been a problem ever since it was 
introduced (I can never seem to stop naming an identifier I'm going to 
use in an array "length", and any time I use it intentionally it looks 
odd), and we've had the superior "$" for a long time now.  As a result, 
"length" is becoming even more of a problem because I forget it even 
exists, and I'm sure there are people who don't know of the superior 
alternative.  I think it's now time to go to the next step and deprecate 
and eventually remove this bad thing.


I'm just the opposite.  I'd completely forgotten '$' exists because I've never
used it.  I mich prefer the 'length' convention.


Sean
Oct 22 2005
next sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Sean Kelly wrote:

 In article <djcipj$ilp$1 digitaldaemon.com>, Burton Radons says...
 

The contextual identifier "length" has been a problem ever since it was 
introduced (I can never seem to stop naming an identifier I'm going to 
use in an array "length", and any time I use it intentionally it looks 
odd), and we've had the superior "$" for a long time now.  As a result, 
"length" is becoming even more of a problem because I forget it even 
exists, and I'm sure there are people who don't know of the superior 
alternative.  I think it's now time to go to the next step and deprecate 
and eventually remove this bad thing.


 
 
 I'm just the opposite.  I'd completely forgotten '$' exists because I've never
 used it.  I mich prefer the 'length' convention.
 
 
 Sean
 
 


Ditto. I've didn't like '$' when it was first proposed and I don't like 
it now. Making 'length' a keyword is a much nicer solution, IMO.
Oct 22 2005
parent reply Burton Radons <burton-radons smocky.com> writes:
Mike Parker wrote:

 Sean Kelly wrote:
 

 In article <djcipj$ilp$1 digitaldaemon.com>, Burton Radons says...


 The contextual identifier "length" has been a problem ever since it 
 was introduced (I can never seem to stop naming an identifier I'm 
 going to use in an array "length", and any time I use it 
 intentionally it looks odd), and we've had the superior "$" for a 
 long time now.  As a result, "length" is becoming even more of a 
 problem because I forget it even exists, and I'm sure there are 
 people who don't know of the superior alternative.  I think it's now 
 time to go to the next step and deprecate and eventually remove this 
 bad thing.




 I'm just the opposite.  I'd completely forgotten '$' exists because 
 I've never
 used it.  I mich prefer the 'length' convention.


 Sean


 Ditto. I've didn't like '$' when it was first proposed and I don't like 
 it now. Making 'length' a keyword is a much nicer solution, IMO.


A consequence of that would be the need for special handling of "length" 
member functions and variables for array structures.

I've argued before that all the C type languages have it wrong - 
keywords should be distinct from identifiers.  The way it is now just 
causes problems, such as, say, changing a common identifier into a 
keyword and breaking five years of code.  Languages, like software, 
should be designed with the expectation of change.
Oct 22 2005
parent Sean Kelly <sean f4.ca> writes:
In article <djdtqk$2ht$1 digitaldaemon.com>, Burton Radons says...

I've argued before that all the C type languages have it wrong - 
keywords should be distinct from identifiers.  The way it is now just 
causes problems, such as, say, changing a common identifier into a 
keyword and breaking five years of code.  Languages, like software, 
should be designed with the expectation of change.


We could always make D like Fortran and have all keywords be non-reserved.  Then
there wouldn't be any problems ;-)


SEan
Oct 22 2005
prev sibling parent reply David Medlock <noone nowhere.com> writes:
Sean Kelly wrote:

 In article <djcipj$ilp$1 digitaldaemon.com>, Burton Radons says...
 

The contextual identifier "length" has been a problem ever since it was 
introduced (I can never seem to stop naming an identifier I'm going to 
use in an array "length", and any time I use it intentionally it looks 
odd), and we've had the superior "$" for a long time now.  As a result, 
"length" is becoming even more of a problem because I forget it even 
exists, and I'm sure there are people who don't know of the superior 
alternative.  I think it's now time to go to the next step and deprecate 
and eventually remove this bad thing.


 
 
 I'm just the opposite.  I'd completely forgotten '$' exists because I've never
 used it.  I mich prefer the 'length' convention.
 
 
 Sean
 
 


I also dislike $.  Very bad in the re-reading of code, imo.

So you are suggesting :

void foo( int[] arr )
{
   int len = arr.$ ;
}

How do we access the length?

-DavidM
Oct 24 2005
parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
David Medlock wrote:

 Sean Kelly wrote:
 

 In article <djcipj$ilp$1 digitaldaemon.com>, Burton Radons says...


 The contextual identifier "length" has been a problem ever since it 
 was introduced (I can never seem to stop naming an identifier I'm 
 going to use in an array "length", and any time I use it 
 intentionally it looks odd), and we've had the superior "$" for a 
 long time now.  As a result, "length" is becoming even more of a 
 problem because I forget it even exists, and I'm sure there are 
 people who don't know of the superior alternative.  I think it's now 
 time to go to the next step and deprecate and eventually remove this 
 bad thing.




 I'm just the opposite.  I'd completely forgotten '$' exists because 
 I've never
 used it.  I mich prefer the 'length' convention.


 Sean


 I also dislike $.  Very bad in the re-reading of code, imo.
 
 So you are suggesting :
 
 void foo( int[] arr )
 {
   int len = arr.$ ;
 }
 
 How do we access the length?
 
 -DavidM


Is it technically possible to support both

#int[] arr;
#int len = arr.length;

and

#int[] arr;
#int[] b = arr[0..$-2];

That way

#int[] arr;
#arr ~= 1;	// arr.length == 1
#int length = 5;
#int[] b = arr[0..length];

would become ambiguous (--> compile time error) or use the local 
variable instead (i.e. arr[0..length] == arr[0..5]).
Oct 24 2005
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Burton Radons" <burton-radons smocky.com> wrote in message 
news:djcipj$ilp$1 digitaldaemon.com...

 The contextual identifier "length" has been a problem ever since it was 
 introduced (I can never seem to stop naming an identifier I'm going to use 
 in an array "length", and any time I use it intentionally it looks odd), 
 and we've had the superior "$" for a long time now.  As a result, "length" 
 is becoming even more of a problem because I forget it even exists, and 
 I'm sure there are people who don't know of the superior alternative.  I 
 think it's now time to go to the next step and deprecate and eventually 
 remove this bad thing.


I hate $.  It doesn't say "length" to me.  You know what does?  "length."  $ 
says "string,"  or maybe "money."  $ doesn't even look pretty enough to be 
in D.

What's wrong with "length" anyway?  So you have to make sure you don't try 
to use a variable named "length" in the same scope.  Oh well.  "length" is 
almost a D standard, that it might as well be a reserved identifier anyway.
Oct 22 2005
parent Chris Sauls <ibisbasenji gmail.com> writes:
Jarrett Billingsley wrote:

 "Burton Radons" <burton-radons smocky.com> wrote in message 
 news:djcipj$ilp$1 digitaldaemon.com...
 

The contextual identifier "length" has been a problem ever since it was 
introduced (I can never seem to stop naming an identifier I'm going to use 
in an array "length", and any time I use it intentionally it looks odd), 
and we've had the superior "$" for a long time now.  As a result, "length" 
is becoming even more of a problem because I forget it even exists, and 
I'm sure there are people who don't know of the superior alternative.  I 
think it's now time to go to the next step and deprecate and eventually 
remove this bad thing.


 
 
 I hate $.  It doesn't say "length" to me.  You know what does?  "length."  $ 
 says "string,"  or maybe "money."  $ doesn't even look pretty enough to be 
 in D.
 
 What's wrong with "length" anyway?  So you have to make sure you don't try 
 to use a variable named "length" in the same scope.  Oh well.  "length" is 
 almost a D standard, that it might as well be a reserved identifier anyway. 
 
 


I must be a freak, because for me the '$' absolutely screams 'length'.  But
maybe that's 
from too much time spent on White-descendant platforms, such as Tiny, Lambda,
and ColdC, 
where the expression:


Is identical to D's:


-- Chris Sauls
Oct 22 2005
prev sibling next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Burton Radons wrote:

 The contextual identifier "length" has been a problem ever since it was 
 introduced (I can never seem to stop naming an identifier I'm going to 
 use in an array "length", and any time I use it intentionally it looks 
 odd), and we've had the superior "$" for a long time now.  As a result, 
 "length" is becoming even more of a problem because I forget it even 
 exists, and I'm sure there are people who don't know of the superior 
 alternative.  I think it's now time to go to the next step and deprecate 
 and eventually remove this bad thing.


How is "length" any different than "sizeof" "ptr" "dup" "reverse" and 
"sort" ?

Here's what I suggest:

1) While 'length' is good, I wouldn't mind subsituting it for 'len'

2) I don't think we should waste the '$' symbol just for length, why not 
spread it across all properties to be consistent?

array.$len
array.$ptr
array.$reverse
array.$sort

Here's a good thread so we don't repeat too much previous discussions.
http://www.digitalmars.com/d/archives/digitalmars/D/17942.html
Oct 22 2005
parent reply Vathix <chris dprogramming.com> writes:
On Sat, 22 Oct 2005 15:59:19 -0400, clayasaurus <clayasaurus gmail.com>  
wrote:


 Burton Radons wrote:

 The contextual identifier "length" has been a problem ever since it was  
 introduced (I can never seem to stop naming an identifier I'm going to  
 use in an array "length", and any time I use it intentionally it looks  
 odd), and we've had the superior "$" for a long time now.  As a result,  
 "length" is becoming even more of a problem because I forget it even  
 exists, and I'm sure there are people who don't know of the superior  
 alternative.  I think it's now time to go to the next step and  
 deprecate and eventually remove this bad thing.


 How is "length" any different than "sizeof" "ptr" "dup" "reverse" and  
 "sort" ?


Because length can be used without specifying the variable name being used  
if it's in an array or slice subscript. The others can't do that. A lot of  
people are using "length" for other variable names and it will cause (and  
already is) a lot of grief. When this magic length was added, I stated  
that I'm glad I named my length variables "len" and avoided this. For some  
reason, I still don't like $ for length; but I can't say that I've given  
it much of a chance becuase it hasn't been widely accepted yet (I believe  
it's even still a trial feature). I do prefer $ over length due to the  
above reasons, however.

I think this magic "length" should be deprecated.

Compromise: $length might be the best solution.

Someone suggested "len" instead of "length", I think it's worse ;)


 Here's a good thread so we don't repeat too much previous discussions.
 http://www.digitalmars.com/d/archives/digitalmars/D/17942.html


"How about xx for "something big" and $ for length?"
    xx ->
Oct 22 2005
parent reply clayasaurus <clayasaurus gmail.com> writes:
Vathix wrote:

 On Sat, 22 Oct 2005 15:59:19 -0400, clayasaurus <clayasaurus gmail.com>  
 wrote:
 

 Burton Radons wrote:


 The contextual identifier "length" has been a problem ever since it 
 was  introduced (I can never seem to stop naming an identifier I'm 
 going to  use in an array "length", and any time I use it 
 intentionally it looks  odd), and we've had the superior "$" for a 
 long time now.  As a result,  "length" is becoming even more of a 
 problem because I forget it even  exists, and I'm sure there are 
 people who don't know of the superior  alternative.  I think it's now 
 time to go to the next step and  deprecate and eventually remove this 
 bad thing.



 How is "length" any different than "sizeof" "ptr" "dup" "reverse" and  
 "sort" ?


 
 
 Because length can be used without specifying the variable name being 
 used  if it's in an array or slice subscript. The others can't do that. 
 A lot of  people are using "length" for other variable names and it will 
 cause (and  already is) a lot of grief. When this magic length was 
 added, I stated  that I'm glad I named my length variables "len" and 
 avoided this. For some  reason, I still don't like $ for length; but I 
 can't say that I've given  it much of a chance becuase it hasn't been 
 widely accepted yet (I believe  it's even still a trial feature). I do 
 prefer $ over length due to the  above reasons, however.
 
 I think this magic "length" should be deprecated.


Ahh. Ok, I guess I missed the whole point then. I agree it should be 
depreciated, but I don't agree it should be replaced with $, since $ is 
not intuitive.


 
 Compromise: $length might be the best solution.
 


I like it! Perhaps even  length (  = 'a' = 'array' in my mind).

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


 Someone suggested "len" instead of "length", I think it's worse ;)
 


I can see why :-P


 Here's a good thread so we don't repeat too much previous discussions.
 http://www.digitalmars.com/d/archives/digitalmars/D/17942.html


 
 
 "How about xx for "something big" and $ for length?"
    xx ->
Oct 22 2005
parent reply sai <sai_member pathlink.com> writes:
I vote for '$' being a short form of 'with' for all objects including arrays
like this:

--------------------------
Instead of 
array[ length - 2 ] 

Use:
array[ $length - 2 ]

--------------------------
Instead of 
user_defined_matrix[ user_defined_matrix.rank - 2 ]

Use:
user_defined_matrix[ $rank - 2 ]

----------------------------
Instead of 
some_object.method1( some_object.method2(arg1) ~ "blahblah" )

Use:
some_object.method1( $method2(arg1) ~ "blahblah" )
// assuming method2 returns a string.

------------------------------

Whay do you guys say ?
wishes
Sai
Oct 24 2005
next sibling parent clayasaurus <clayasaurus gmail.com> writes:
I like it better than just using '$' . At least it can be used for other 
purposes this way and isn't entirely wasted.

sai wrote:

 I vote for '$' being a short form of 'with' for all objects including arrays
 like this:
 
 --------------------------
 Instead of 
 array[ length - 2 ] 
 
 Use:
 array[ $length - 2 ]
 
 --------------------------
 Instead of 
 user_defined_matrix[ user_defined_matrix.rank - 2 ]
 
 Use:
 user_defined_matrix[ $rank - 2 ]
 
 ----------------------------
 Instead of 
 some_object.method1( some_object.method2(arg1) ~ "blahblah" )
 
 Use:
 some_object.method1( $method2(arg1) ~ "blahblah" )
 // assuming method2 returns a string.
 
 ------------------------------
 
 Whay do you guys say ?
 wishes
 Sai
Oct 24 2005
prev sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <djj2o5$14u4$1 digitaldaemon.com>, sai says...

I vote for '$' being a short form of 'with' for all objects including arrays
like this:

--------------------------
Instead of 
array[ length - 2 ] 

Use:
array[ $length - 2 ]


I don't like it and I don't think I'll use it.

less offencive to me would be "$."
array[ $.length - 2 ]

Ant
Oct 24 2005
next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <djj7lk$19fr$1 digitaldaemon.com>, Ant says...

In article <djj2o5$14u4$1 digitaldaemon.com>, sai says...

I vote for '$' being a short form of 'with' for all objects including arrays
like this:

--------------------------
Instead of 
array[ length - 2 ] 

Use:
array[ $length - 2 ]


I don't like it and I don't think I'll use it.

less offencive to me would be "$."
array[ $.length - 2 ]


that could also be used on the with block
(I don't know about nested with - maybe it's not allowed)

Ant
Oct 24 2005
parent Oskar Linde <Oskar_member pathlink.com> writes:
In article <djjhv8$1ici$1 digitaldaemon.com>, Ant says...

In article <djj7lk$19fr$1 digitaldaemon.com>, Ant says...

In article <djj2o5$14u4$1 digitaldaemon.com>, sai says...

I vote for '$' being a short form of 'with' for all objects including arrays
like this:

--------------------------
Instead of 
array[ length - 2 ] 

Use:
array[ $length - 2 ]


I don't like it and I don't think I'll use it.

less offencive to me would be "$."
array[ $.length - 2 ]


that could also be used on the with block
(I don't know about nested with - maybe it's not allowed)


A reference to the outer with block would be .$.length ;)

/Oskar
Oct 24 2005
prev sibling parent reply Don Clugston <dac nospam.com.au> writes:
Ant wrote:

 In article <djj2o5$14u4$1 digitaldaemon.com>, sai says...
 

I vote for '$' being a short form of 'with' for all objects including arrays
like this:

--------------------------
Instead of 
array[ length - 2 ] 

Use:
array[ $length - 2 ]


 
 
 I don't like it and I don't think I'll use it.
 
 less offencive to me would be "$."
 array[ $.length - 2 ]
 
 Ant


I agree, and was thinking the same thing.
Then you could also use $.typeof, etc -- it does seem to me that length 
is not the only case that is useful.
This would also mean that the syntax like $abc is still available.
Oct 24 2005
parent Dan <Dan_member pathlink.com> writes:
It would be reasonable to use it as a variable, but I mean, then why
not use "a"?  Seriously, if you have problems typing out length, or
don't like the variable, then use a different one.

The syntax doesn't matter in the grand scheme beyond it being readable
and consistent.  We want it to be regular and effective at expressing
the concept.  "arr.length" expresses exactly what we want and is
consistent.

"$" is not.  I have no idea what it means, and it takes just as long
to type cause of the shift key.

I used to think it might be a powerful thing in JavaScript to override
the "." so if you went:

"Matrix.
multiply(x){...};
divide(x){...   .inverse() ...}
"

It seems to be able to very tersely eliminate with/this.  In JavaScript,
where code size is very important, it matters.  In D it has no significance
and makes code impossible to read.
Oct 25 2005
prev sibling next sibling parent David L. Davis <SpottedTiger yahoo.com> writes:
In article <djcipj$ilp$1 digitaldaemon.com>, Burton Radons says...

The contextual identifier "length" has been a problem ever since it was 
introduced (I can never seem to stop naming an identifier I'm going to 
use in an array "length", and any time I use it intentionally it looks 
odd), and we've had the superior "$" for a long time now.  As a result, 
"length" is becoming even more of a problem because I forget it even 
exists, and I'm sure there are people who don't know of the superior 
alternative.  I think it's now time to go to the next step and deprecate 
and eventually remove this bad thing.


Sorry Burton, but I'm on the opposite side of this issue...I'm always forgetting
about the '$' (dollar-sign) being length, I did't think it was a good idea back
in dmd v0.116 when it was created, and don't use it now, and I won't use it in
the future! I think that the '$' should be the one deprecated out of D, and to
leave the 'length' within arrays alone. Frankly, I'm always using the array name
then the '.length', but if 'length' stays in, I would go with using the 'length'
stand-alone in arrays. (Forget about wasting '$' token for this! Better to use
it for a Meta-Programming token or something more useful!)

Highest regards,
David L.

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

MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html
Oct 22 2005
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 21 Oct 2005 22:30:25 +0000, Burton Radons wrote:


 The contextual identifier "length" has been a problem ever since it was 
 introduced (I can never seem to stop naming an identifier I'm going to 
 use in an array "length", and any time I use it intentionally it looks 
 odd), and we've had the superior "$" for a long time now.  As a result, 
 "length" is becoming even more of a problem because I forget it even 
 exists, and I'm sure there are people who don't know of the superior 
 alternative.  I think it's now time to go to the next step and deprecate 
 and eventually remove this bad thing.


I only use '$' and never 'length'. Actually, I never use 'length', or any
standard English word, as an identifier name either. The use of these words
exposes a program to future changes in the reserved word list of the
language. I prefer to avoid this risk.

I suggested '$' to Walter because of its existing usage in regular
expression syntaxes - in which it represents the end of a line (not the
last character) thus I naturally see '$' as the length symbol. However,
regardless of which symbol token that Walter would have chosen, that symbol
would have been better than a word which could also be an identifier name
in other contexts.

-- 
Derek Parnell
Melbourne, Australia
23/10/2005 7:55:17 AM
Oct 22 2005
next sibling parent Carlos Santander <csantander619 gmail.com> writes:
Derek Parnell escribió:

 
 I only use '$' and never 'length'.
 


Same here. I didn't even remember about that special case. Thanks for reminding 
me... That said, I vot for $ to stay and "length" to go.

-- 
Carlos Santander Bernal
Oct 22 2005
prev sibling parent Sean Kelly <sean f4.ca> writes:
In article <129emmh9luoam.1if5cpo9j11ib$.dlg 40tude.net>, Derek Parnell says...

I suggested '$' to Walter because of its existing usage in regular
expression syntaxes - in which it represents the end of a line (not the
last character) thus I naturally see '$' as the length symbol.


Ah, that makes sense.  I'd forgotten about this aspect of regular expressions.
At least I now know why '$' was chosen :-)


Sean
Oct 22 2005
prev sibling next sibling parent reply "Kris" <fu bar.com> writes:
Ouch! Someone just jabbed a sharp stick into my ribs.

For those who don't recall, here's an attempt to capture some history:


The problem
=========

For purposes of illustration:













That function is supposed to return the subset of its argument only as far 
as a newline, or all of it if there's no newline present. Do you see the 
insideous bug there? Many of you will not, so here's the beef:

Walter added a very subtle pseudo-reserved word, that's only used when it 
comes to arrays. Yes, it's that word "length". When used within 
square-brackets, it always means "the length of the enclosing array". Of 
course, this overrides any other variable (or function) that happens to be 
called "length". Naturally, no warning is emitted, and the result is a nasty 
and difficult to spot bug.


Why was this introduced?
=================

The problem originated where one might need to reference the array-length 
within a sub-expression; typically an expression within the array brackets 
themselves. This extended to templates, which required a means to explicitly 
reference the array length whilst avoiding recanting the array itself (or 
something like that ~ I'm just relying on memory here).

The upshot, I understand, was that the notion of an implicit array-length 
'temporary' seemed appropriate. Unfortunately it was implemented as a 
pseudo-reserved "length", rather than in some alternate manner that didn't 
quite shove it up the programmers' proverbial arse. So to speak.


How did the '$' thing happen?
===================

There was actually some notable* concensus on a resolution, using '$' (or 
some other character) as a prefix. Thus we might have had $length or $len, 
$argptr, $arguments, $file, $line, and $timestamp which, by the nature of 
reserving the $ prefix, would have left the door open for D to optionally 
add further "meta keywords" down the road; and, most importantly, without 
the possibility of collision against programmer-defined identifiers such as 
variable-names. Any old prefix would have worked, as long as it were 
/reserved/ for compiler usage only.

Instead, that notion was abandoned in favour of reserving $ explicitly, and 
solely, to replace the fragile usage of "length" within arrays. Having said 
that, $ within arrays is apparently still a "test", and said use of length 
within array-brackets is still supported at this time.


The upshot
========

Some comments posted thus far might lead one to believe the issue is one of 
"what looks nicer". While that may be important, this topic is about 
something of greater substance ~ IMO ~ I sincerely hope that has been made 
reasonably clear.

Burton is saying: "isn't it time to drop the fragile meaning of length 
completely (remove that special case from the compiler), and move '$' to a 
more permanent status?". He is not trying to say that '$' is somehow better 
than 'length', or vice versa. We've beaten that to death in the past.

For my money, I'd like to see the "prefix" approach adopted. Yet I seriously 
doubt that will happen. In leui of that, I'll second Burton's request to 
solidify, or <gasp> maybe even wrap up, the status of this long-running 
issue.


- Kris


* Notable in that concensus on this NG is exceptionally rare.
Oct 22 2005
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <djeht6$k60$1 digitaldaemon.com>, Kris says...

There was actually some notable* concensus on a resolution, using '$' (or 
some other character) as a prefix. Thus we might have had $length or $len, 
$argptr, $arguments, $file, $line, and $timestamp which, by the nature of 
reserving the $ prefix, would have left the door open for D to optionally 
add further "meta keywords" down the road; and, most importantly, without 
the possibility of collision against programmer-defined identifiers such as 
variable-names. Any old prefix would have worked, as long as it were 
/reserved/ for compiler usage only.

Instead, that notion was abandoned in favour of reserving $ explicitly, and 
solely, to replace the fragile usage of "length" within arrays. Having said 
that, $ within arrays is apparently still a "test", and said use of length 
within array-brackets is still supported at this time.


..

For my money, I'd like to see the "prefix" approach adopted. Yet I seriously 
doubt that will happen. In leui of that, I'll second Burton's request to 
solidify, or <gasp> maybe even wrap up, the status of this long-running 
issue.


For me, this has been one of those "I've never done it, so what's the problem"
issues.  But I I agree that the 'length' token, by itself, can cause subtle
errors, and there's no reason to have the potential for that in D.  I somewhat
prefer the prefix idea as well, though now that I know that the '$' symbol was
chosen for its meaning in regular expressions, I'm not sure I could see it as
anything else.  Count me as a part of the "it's been long enough, get rid of
'length'" contingent.


Sean
Oct 22 2005
prev sibling parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak invalid_utu.fi> writes:
Kris wrote:

 There was actually some notable* concensus on a resolution, using '$' (or 
 some other character) as a prefix. Thus we might have had $length or $len, 
 $argptr, $arguments, $file, $line, and $timestamp which, by the nature of 
 reserving the $ prefix, would have left the door open for D to optionally 
 add further "meta keywords" down the road; and, most importantly, without 
 the possibility of collision against programmer-defined identifiers such as 
 variable-names. Any old prefix would have worked, as long as it were 
 /reserved/ for compiler usage only.


I vote for this prefix version. It is much more general than the other 
suggestions. Sometimes it's hard to notice these currently used 'magic' 
variables from other people's messy code as they have too regular names.
Oct 23 2005
prev sibling next sibling parent =?utf-8?B?RGF3aWQgQ2nEmcW8YXJraWV3aWN6?= <araelx gmail.com> writes:
On Sat, 22 Oct 2005 00:30:25 +0200, Burton Radons  
<burton-radons smocky.com> wrote:


 The contextual identifier "length" has been a problem ever since it was  
 introduced (I can never seem to stop naming an identifier I'm going to  
 use in an array "length", and any time I use it intentionally it looks  
 odd), and we've had the superior "$" for a long time now.  As a result,  
 "length" is becoming even more of a problem because I forget it even  
 exists, and I'm sure there are people who don't know of the superior  
 alternative.  I think it's now time to go to the next step and deprecate  
 and eventually remove this bad thing.


Yes. As I can remember Walter said that it will be completly removed from  
language in the future (Changlog for 0.116) - the question is "when". I  
vote for "soon" too.

And personaly, I hope no change will be made to '$' sign. Especialy  
concepts with mixed syntax like  length scares me a bit. ! jus4 d*n'4 l!k&  
m!xed th!ng$. Of course it's only matter of taste, but does [0 .. $] looks  
bad? Having stricly "lenght" word there - is like ... changing:
void main()
into:
function main() : void
Not bad, but we live without it "from the begining of time" and there is  
no problem. :)
-- 
Dawid Ciężarkiewicz
Oct 23 2005
prev sibling next sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Am I the only one to actually prefer:

   arr[0 .. arr.length]

?
I don't like plain length because of the aforementioned name conflicts, 
but I don't like $ either because it is just... well, ugly and 
inexpressive maybe?

Is there any problem with my approach? I guess it doesn't work with 
anonymous arrays, but the only such thing is array literals, right? 
Which I don't think one would want to use the index operator on (and 
which aren't even currently implemented).

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to 
be... unnatural."
Oct 24 2005
next sibling parent Don Clugston <dac nospam.com.au> writes:
Bruno Medeiros wrote:

 
 Am I the only one to actually prefer:
 
   arr[0 .. arr.length]
 
 ?
 I don't like plain length because of the aforementioned name conflicts, 
 but I don't like $ either because it is just... well, ugly and 
 inexpressive maybe?



 
 Is there any problem with my approach? I guess it doesn't work with 
 anonymous arrays, but the only such thing is array literals, right? 
 Which I don't think one would want to use the index operator on (and 
 which aren't even currently implemented).


I agree. Couldn't some variation on .length, this.length be used?
$ seems like a terrible waste of a precious symbol.
I would like to see $ used for something seriously powerful, like 
compile-time variables.
Oct 24 2005
prev sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Bruno Medeiros wrote:

 
 Am I the only one to actually prefer:
 
   arr[0 .. arr.length]
 
 ?
 I don't like plain length because of the aforementioned name conflicts, 
 but I don't like $ either because it is just... well, ugly and 
 inexpressive maybe?
 
 Is there any problem with my approach? I guess it doesn't work with 
 anonymous arrays, but the only such thing is array literals, right? 
 Which I don't think one would want to use the index operator on (and 
 which aren't even currently implemented).
 


Only one:

someTemplate!(type1,type2).object.method[somekey].getSomeCrazyArray[
0..someTemplate!(type1,type2).object.method[somekey].getSomeCrazyArray.length]

:-)

I think cases like this are the reason to try to make it shorter in the 
first place.
Oct 24 2005
prev sibling parent reply James McComb <ned jamesmccomb.id.au> writes:
Burton Radons wrote:


 The contextual identifier "length" has been a problem ever since it was 
 introduced (I can never seem to stop naming an identifier I'm going to 
 use in an array "length", and any time I use it intentionally it looks 
 odd), and we've had the superior "$" for a long time now.  As a result, 
 "length" is becoming even more of a problem because I forget it even 
 exists, and I'm sure there are people who don't know of the superior 
 alternative.  I think it's now time to go to the next step and deprecate 
 and eventually remove this bad thing.


Why is a symbol necessary at all? What's wrong with:

arr[3..] // from 3 to arr.length
arr[..3] // from 0 to 3
arr[..]  // from 0 to arr.length (instead of arr.dup)

James McComb
Oct 24 2005
next sibling parent reply Vathix <chris dprogramming.com> writes:
On Mon, 24 Oct 2005 19:23:49 -0400, James McComb <ned jamesmccomb.id.au>  
wrote:


 Why is a symbol necessary at all? What's wrong with:

 arr[3..] // from 3 to arr.length
 arr[..3] // from 0 to 3


then people want arr[3 .. -1]


 arr[..]  // from 0 to arr.length (instead of arr.dup)


why would that dup, other slices don't dup
Oct 24 2005
parent James McComb <ned jamesmccomb.id.au> writes:
Vathix wrote:


 arr[..]  // from 0 to arr.length (instead of arr.dup)





 why would that dup, other slices don't dup


My mistake.

James McComb
Oct 25 2005
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Tue, 25 Oct 2005 09:23:49 +1000, James McComb wrote:


 Burton Radons wrote:
 

 The contextual identifier "length" has been a problem ever since it was 
 introduced (I can never seem to stop naming an identifier I'm going to 
 use in an array "length", and any time I use it intentionally it looks 
 odd), and we've had the superior "$" for a long time now.  As a result, 
 "length" is becoming even more of a problem because I forget it even 
 exists, and I'm sure there are people who don't know of the superior 
 alternative.  I think it's now time to go to the next step and deprecate 
 and eventually remove this bad thing.


 
 Why is a symbol necessary at all? What's wrong with:
 
 arr[3..] // from 3 to arr.length
 arr[..3] // from 0 to 3
 arr[..]  // from 0 to arr.length (instead of arr.dup)
 
 James McComb


The absence of a 'length'-type token in the text of your source can be lost
in the surrounding 'clutter' and thus reduce the reader's understanding of
your code.

   SomeFunc(Found.Files[Last.FoundIndex+1..],Some.Other,Useful.Parameters);

whereas the inclusion of a positive visual signal can improve the
legibility of your code and thus reduce maintenance costs.

The argument is mostly concerned with what is the most appropriate positive
visual signal we should use to represent the array length concept in this
context.

Current contenders seem to be ... 

 length
 arr.length
 .length
 len
 $
 $length
 $.length

 #length
 
Of these, I favour all those that have a no possibility of being mistaken
for a reserved word, an identifier, or an existing token in other contexts.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
25/10/2005 9:37:20 AM
Oct 24 2005