View mode: basic / threaded / horizontal-split · Log in · Help
October 23, 2005
Re: It's time to deprecate "array [length]" in favour of "array [$]"
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
October 23, 2005
Re: It's time to deprecate "array [length]" in favour of "array [$]"
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.
October 23, 2005
Re: It's time to deprecate "array [length]" in favour of "array [$]"
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
October 24, 2005
Re: It's time to deprecate "array [length]" in favour of "array [$]"
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."
October 24, 2005
Re: It's time to deprecate "array [length]" in favour of "array [$]"
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.
October 24, 2005
Re: It's time to deprecate
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
October 24, 2005
Re: It's time to deprecate "array [length]" in favour of "array [$]"
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.
October 24, 2005
Re: It's time to deprecate
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]).
October 24, 2005
more general use of $ [was -- It's time to deprecate ]
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
October 24, 2005
Re: more general use of $ [was -- It's time to deprecate ]
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
> 
> 
>
1 2 3 4
Top | Discussion index | About this forum | D home