March 14, 2005 Re: $; shall we declare time? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kris | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jon Andrew | > 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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ben Hinkle | "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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kris | "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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | >> >>> ./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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Vathix | 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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Anders F Björklund | 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? | ||||
---|---|---|---|---|
| ||||
Posted in reply to J C Calvarese | 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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | 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 |
Copyright © 1999-2021 by the D Language Foundation