Kris wrote:
> Forgive me, but I didn't see much, if any, criticism of the following which was
> posted early on:
> 
> $length

I prefer the shorter variant "$len", but I can live with "$length".

Either way is much better than what we were stuck with a couple months ago when an array length was hiding other lengths. That was an error obscurer if I ever saw one.

> $argptr
> $arguments
> $file
> $line
> $timestamp
> 
> or the alternative:
> 
> @length
> @argptr
> @arguments
> @file
> @line
> @timestamp

Either $ or @ looks good to me.

> Don't wish to drag this out any longer than it has to be, but, please remind me
> of the arguments against collating all such meta-tags together under one roof
> .. there's a number of benefits in adopting the above, right? 
> 
> I'm certainly not too fond of adopting a __NAME__ approach for __file__ et. al.,
> so what are the alternatives there? And then what about _arguments and _argptr?

One underscore is cute. Two are a lack of creativity. ;)


-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

> Aye, typing out arr.length really isn't such a big hassle anyway, is it?

That isn't, but if you have

foo(somefunc(some,params)[length-1]);

you need a temporary var to do it, which is a hassle (keeps the reference, too, so can't be GC'ed unless you null it, which is even more hassle)


xs0

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d0s2vk$1rgs$1@digitaldaemon.com...
>
> "Derek Parnell" <derek@psych.ward> wrote in message news:onv6vwm3agbo$.1ezjtrb8uag1.dlg@40tude.net...
> > On Thu, 10 Mar 2005 23:03:58 -0600, J C Calvarese wrote:
> >
> >> Ben Hinkle wrote:
> >>> I don't know if this has been already proposed but I was pondering the "negative index" and the "missing index" proposals and it occurred to
me
> >>> that a place-holder that would be (a) an identifier, (b) unobtrusive
and
> >>> (c)
> >>> unlikely to be used by a real coder is an underscore. I grepped phobos
> >>> for
> >>> some examples of a[a.length] and replaced them with a[_] to get a feel
> >>> for
> >>> how it would look. At one point Walter proposed making it an error to
> >>> have
> >>> the "magic length identifier" shadow a symbol with the same name - and
I
> >>> think that would catch any yahoo who actually wants to have symbols named _
> >>>
> >>> ./std/format.d: putstr(tmpbuf[n .. _]);
> >>> ./std/math2.d: real result = coefficients[_ - 1];
> >>
> >> I like it. It's clever.
> >>
> > It is significantly more difficult to see. Not every one has 20-y.o.
eyes
> > any more? ;-)
>
> When surrounded by spaces it should be easier to pick out, but I agree visibility is the biggest drawback.

While technically it will work fine, it just doesn't look right. It looks like an attempt to draw a picture with ASCII art. The visual appearance matters as much as the technical merits.

"Kris" <Kris_member@pathlink.com> wrote in message news:d0t1vg$9nd$1@digitaldaemon.com...
> I'm certainly not too fond of adopting a __NAME__ approach for __file__
et. al.,
> so what are the alternatives there?

I'm not too fond of its look either, but things like __FILE__ and __LINE__ are so deeply embedded in the psyche, it's instantly recognizable even for people who've never seen D before. That's a powerful current to swim against. D can diverge in appearance from C++ up to a point, I don't know where that point is, but once we're past it then D may look so different that people will be put off from learning it and dump it into the Eiffel bin.

I'm not really sure why Eiffel failed to catch on, but it's visual appearance I find personally off-putting.

> And then what about _arguments and _argptr?

I'd rather stick with _ as a prefix rather than $, just because it's longstanding C tradition for naming internal system variables.

In article <d14n7i$2aa9$1@digitaldaemon.com>, Walter says...
>
>
>"Kris" <Kris_member@pathlink.com> wrote in message news:d0t1vg$9nd$1@digitaldaemon.com...
>> I'm certainly not too fond of adopting a __NAME__ approach for __file__
>et. al.,
>> so what are the alternatives there?
>
>I'm not too fond of its look either, but things like __FILE__ and __LINE__ are so deeply embedded in the psyche, it's instantly recognizable even for people who've never seen D before. That's a powerful current to swim against. D can diverge in appearance from C++ up to a point, I don't know where that point is, but once we're past it then D may look so different that people will be put off from learning it and dump it into the Eiffel bin.

For someone such as myself who doesn't bring much C baggage to my D perspective __FILE__ and __LINE__ looks more like a failed attempt at ASCII art than programming. Please don't take D down this road!

Either $ or @ looks cool to me.

>
>I'm not really sure why Eiffel failed to catch on, but it's visual appearance I find personally off-putting.
>
>> And then what about _arguments and _argptr?
>
>I'd rather stick with _ as a prefix rather than $, just because it's longstanding C tradition for naming internal system variables.

I thought outdated long-standing C traditions are much of the reason for D. (C doesn't need objects, garbage collections, modules, array slicing, templates, mixins, and operator overloading, so neither does D?)

jcc7

>> >>> ./std/math2.d: real result = coefficients[_ - 1];
>> >>
>> >> I like it. It's clever.
>> >>
>> > It is significantly more difficult to see. Not every one has 20-y.o.
> eyes
>> > any more? ;-)
>>
>> When surrounded by spaces it should be easier to pick out, but I agree
>> visibility is the biggest drawback.
>
> While technically it will work fine, it just doesn't look right. It looks
> like an attempt to draw a picture with ASCII art. The visual appearance
> matters as much as the technical merits.

hah.   [_.._] looks disturbing.

Vathix wrote:

>> While technically it will work fine, it just doesn't look right. It looks
>> like an attempt to draw a picture with ASCII art. The visual appearance
>> matters as much as the technical merits.
> 
> hah.   [_.._] looks disturbing.

I'm not sure that [$..$] is all good either. Looks a bit... commercial ?
Especially since the compiler pronounces it as "(__dollar)", in errors.

At least [_length .. _length] looks *somewhat* sane, in all the madness.

--anders

On Mon, 14 Mar 2005 21:01:31 +0100, Anders F Björklund wrote:

> Vathix wrote:
> 
>>> While technically it will work fine, it just doesn't look right. It looks like an attempt to draw a picture with ASCII art. The visual appearance matters as much as the technical merits.
>> 
>> hah.   [_.._] looks disturbing.
> 
> I'm not sure that [$..$] is all good either. Looks a bit... commercial ? Especially since the compiler pronounces it as "(__dollar)", in errors.
> 
> At least [_length .. _length] looks *somewhat* sane, in all the madness.
> 
> --anders

Except that its not runnable. The first index must be a value from 0 to array.length-1
-- 
Derek Parnell
Melbourne, Australia
15/03/2005 7:08:29 AM

J C Calvarese wrote:

> For someone such as myself who doesn't bring much C baggage to my D perspective
> __FILE__ and __LINE__ looks more like a failed attempt at ASCII art than
> programming. Please don't take D down this road! 

If anything, it was already *on* that road. The question is whether
these "once-in-a-blue-moon" variables are reason enough to leave it ?

> Either $ or @ looks cool to me.

Me too, so my Perl code uses a lot of both of them. And % too... :-)

Just that there seemed like no really good reason to add them to D,
just because Walter used "length" instead of "_length" in DMD 0.99 ?

> I thought outdated long-standing C traditions are much of the reason for D. (C
> doesn't need objects, garbage collections, modules, array slicing, templates,
> mixins, and operator overloading, so neither does D?)

I'm not sure what replacing one non-alpha character (_) with another
arbitrary choice ($ or @) has to do with any of those new D features ?

Just document "don't use vars starting with underscore", and move on...

--anders

Derek Parnell wrote:

>>I'm not sure that [$..$] is all good either. Looks a bit... commercial ?
>>Especially since the compiler pronounces it as "(__dollar)", in errors.
>>
>>At least [_length .. _length] looks *somewhat* sane, in all the madness.
> 
> Except that its not runnable. The first index must be a value from 0 to
> array.length-1 

Sure it is, you just get an ArrayBoundsError for non-release builds ?

But you are right that $-1 is probably more useful as a starting index.

> import std.stdio;
> int main(char[][] args)
> {
>   char[][] str = args[$-1..$];
>   writefln(str[0]);
>   return 0;
> }

Again, probably better to use "args[args.length-1..args.length]" here.

--anders