View mode: basic / threaded / horizontal-split · Log in · Help
March 14, 2005
Re: $; shall we declare time?
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/
March 14, 2005
Re: $; shall we declare
> 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
March 14, 2005
Re: yalp (yet another length proposal)
"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.
March 14, 2005
Re: $; shall we declare time?
"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.
March 14, 2005
Re: $; shall we declare time?
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
March 14, 2005
Re: yalp (yet another length proposal)
>> >>> ./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.
March 14, 2005
Re: yalp (yet another length proposal)
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
March 14, 2005
Re: yalp (yet another length proposal)
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
March 14, 2005
Re: $; shall we declare time?
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
March 14, 2005
Re: yalp (yet another length proposal)
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
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home