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

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.

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

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."

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.

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

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.

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]).

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

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
> 
> 
>