View mode: basic / threaded / horizontal-split · Log in · Help
March 11, 2005
Re: $; shall we declare time?
In article <d0t3jc$h2o$1@digitaldaemon.com>, Matthew says...
<snip>
>Were the consensus to be that the above $-prefixed list be 
>representative of a general strategy for various meta-ish (meta's the 
>wrong word, I know, given MP) things, then I can live with it, and we 
>can move on to bigger and badder problems. 

Good to explicitly point that out, and I believe that's the general idea here (a
strategic move, rather than the cutest one). 

So, yeah ~ I'm on board with this too.
March 12, 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
> $argptr
> $arguments
> $file
> $line
> $timestamp
> 
> or the alternative:
> 
> @length
> @argptr
> @arguments
> @file
> @line
> @timestamp
> 
> 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?
> 
> Does this point out a problem with NG's in general? ~ perhaps all too often the
> bigger picture is lost to the winds?
> 
> - Kris
> 

I like

@length
@argptr
@arguments

just because $ reminds me of money, or some sort of string. and @ 
reminds me of something like address or location.

maybe i am just the lone sheep that likes the @, but to me it looks 
simple, elegent, smooth and circular. Or like a winding spiral consuming 
itself.

As for criticism? Well I got none other than it eats up an unused 
symbol. But it makes sense, and wraps all those 'weird' keywords into a 
nice little bundle.

> 
> 
> In article <d0t00q$2rl8$1@digitaldaemon.com>, Matthew says...
> 
>>
>>"John Reimer" <brk_6502@yahoo.com> wrote in message 
>>news:d0sdva$27g1$1@digitaldaemon.com...
>>
>>>Derek Parnell wrote:
>>>
>>>
>>>>>>Of all the alternatives, this ones seems to be a better choice. 
>>>>>>It's definitely not perfect, but perfect is hard to come by.
>>>>>
>>>>>Grammar correction: "Of all the alternatives, this one seems to be 
>>>>>the best choice." :-P
>>>>
>>>>
>>>>No it doesn't ;-)
>>>
>>>Ha! :-)
>>
>>Are we yet ready to agree that neither $ not _ not $length have survived 
>>enough criticism to pass, and that therefore all should be deprecated, 
>>and we should, now, move on to more significant flaws in the language.
>>
>>I say we all give Walter a hearty slap on the back for moving to the 
>>try-it-out paradigm, and declare this first one a success (albeit that 
>>it's a success in the negative).
>>
>>Matthew
>>
>>
> 
> 
>
March 12, 2005
Re: $; shall we declare time?
"Kris" <Kris_member@pathlink.com> wrote in message
news:d0t1vg$9nd$1@digitaldaemon.com...
> Forgive me, but I didn't see much, if any, criticism of the following
which was
> posted early on:
>
> $length
> $argptr
> $arguments
> $file
> $line
> $timestamp
>
> or the alternative:
>
> @length
> @argptr
> @arguments
> @file
> @line
> @timestamp

I hate to be "me-too"-ish, but I've lurked around a while, and w.r.t. the
"length" debate, I like this approach best, because it at least makes the
"uglification" consistent.

The big disadvantage is that the dollar or at would imply a relation between
the identifiers where there is not. But I think that the disambiguation/less
namespace pollution outweighs any disadvantages.

As an aside, most times in larger projects that I use "length" in a
variable, it is prefixed (ex. "fileLength"). But I think one of the stated
goals for D was to make "quick-n-dirty" coding of small programs easier, and
the utility/ease of using "length" by itself is very high.

Just my 0.02 USD,
Les Baker
March 12, 2005
Re: yalp (yet another length proposal)
To me, _ looks more like a placeholder for something unnamed. I've often 
played with the idea of using it for closures like:

	fptr = myfunc(_,15);

being equivalent to

	fptr = function(sometype a) { return myfunc(a,15); }

This has several advantages and allows to do thing that cannot be done 
with literal functions (like capturing dynamic values at the time of 
creation of the closure.

But probably the idea is too unclear to bring it up here. I just 
remembered it when seeing _



Ben Hinkle schrieb:
> 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];
> ./std/math2.d: if (s[_ - 1] == 'h')
> ./std/path.d:     return fullname[i .. _];
> ./std/path.d: return fullname[i .. _];
> ./std/path.d: if (fullname.length && fullname[_ - 1] == '.')
> ./std/path.d: if (fullname.length && fullname[_ - 1] == '.')
> ./std/path.d: fullname = fullname[0 .. _ - existing.length] ~ ext;
> ./std/path.d:    return d.length < path.length && path[d.length] == sep[0];
> ./std/path.d:  else if (p1[_ - 1] == '\\')
> ./std/path.d:      p = p1 ~ p2[1 .. _];
> ./std/path.d:     else if (p1[_ - 1] == '\\')
> ./std/path.d: else if (p1[_ - 1] == sep[0])
> ./std/path.d:   if (fnmatch(name[j .. _], pattern[pi + 1 .. _]))
> ./std/regexp.d: result ~= string[p .. _];
> [snip many more examples from phobos] 
> 
>
March 12, 2005
Re: $; shall we declare time?
Considering I was (at least one of) the people who suggested it, I'm on 
board.  Walter?

John Demme

Kris wrote:
> Forgive me, but I didn't see much, if any, criticism of the following which was
> posted early on:
> 
> $length
> $argptr
> $arguments
> $file
> $line
> $timestamp
> 
> or the alternative:
> 
> @length
> @argptr
> @arguments
> @file
> @line
> @timestamp
> 
> 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?
> 
> Does this point out a problem with NG's in general? ~ perhaps all too often the
> bigger picture is lost to the winds?
> 
> - Kris
> 
> 
> 
> In article <d0t00q$2rl8$1@digitaldaemon.com>, Matthew says...
> 
>>
>>"John Reimer" <brk_6502@yahoo.com> wrote in message 
>>news:d0sdva$27g1$1@digitaldaemon.com...
>>
>>>Derek Parnell wrote:
>>>
>>>
>>>>>>Of all the alternatives, this ones seems to be a better choice. 
>>>>>>It's definitely not perfect, but perfect is hard to come by.
>>>>>
>>>>>Grammar correction: "Of all the alternatives, this one seems to be 
>>>>>the best choice." :-P
>>>>
>>>>
>>>>No it doesn't ;-)
>>>
>>>Ha! :-)
>>
>>Are we yet ready to agree that neither $ not _ not $length have survived 
>>enough criticism to pass, and that therefore all should be deprecated, 
>>and we should, now, move on to more significant flaws in the language.
>>
>>I say we all give Walter a hearty slap on the back for moving to the 
>>try-it-out paradigm, and declare this first one a success (albeit that 
>>it's a success in the negative).
>>
>>Matthew
>>
>>
> 
> 
>
March 13, 2005
$ as prefix (and $len vs, $length)
Kris schrieb:
> Forgive me, but I didn't see much, if any, criticism of the following which was
> posted early on:
> 
> $length
> $argptr
> $arguments
> $file
> $line
> $timestamp

I think, this is the cleanest approach so far. The list can easily be 
extended arbitrarily for anything that cannot be parsed quite like a 
regular identifier but is not important enough to be a keyword.

Furthermore, this approach still leaves quite some room for $ to be used 
for other big issues.

Anyhow: I would still prefer $len over $length for reasons I have given 
before.

Ciao,
Norbert
March 13, 2005
Re: $ as prefix (and $len vs, $length)
Norbert Nemec wrote:

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

> I think, this is the cleanest approach so far. The list can easily be 
> extended arbitrarily for anything that cannot be parsed quite like a 
> regular identifier but is not important enough to be a keyword.

But then again, what's the big difference between _ and $ in that case?

Why is:
> $length
> $argptr
> $arguments
> $file
> $line
> $timestamp

Better than:
> _length
> _argptr
> _arguments
> __FILE__
> __LINE__
> __TIMESTAMP__

("length" and "$" are both evil and must be thrown down a cliff,
 _length is only useful for templates - otherwise use AA.length?)

I just don't see the point of changing it, into something so similar ?
But I'm pretty tired of this thread so I'll just wait it out, myself...

> Furthermore, this approach still leaves quite some room for $ to be used 
> for other big issues.

$ @ makes it look like variables to programmers used to shell and Perl, 
just like the `` strings make it look like it runs external programs...

I definitely prefer _name, __NAME__ and r"" over these "alternatives".
Can't say that I plan to use *any* of them in most of the regular code?

They're all pretty specialized, IMHO. (for Templates/Variadics/Logging)
*I* think that you should save $ and @ for something else completely...

--anders
March 13, 2005
Re: $ as prefix (and $len vs, $length)
Anders;

The difference is small but quite significant: '_' is legal within 
user-identifiers (variables, function names, etc) whereas '$' and '@' 
are not.

By using a '$' or '@' as a prefix, Walter can happily extend these 'meta 
tags' without fear of breaking any exisiting code (conflicts in the 
user-namespace) and without having to create a reserved word. Yes, the 
approach has perhaps a touch of compromise to it, but it's a practical 
and forward-thinking resolution. That's more important than an aesthetic 
preference.

- Kris


Anders F Björklund wrote:
> Norbert Nemec wrote:
> 
>> 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?
> 
> 
>> I think, this is the cleanest approach so far. The list can easily be 
>> extended arbitrarily for anything that cannot be parsed quite like a 
>> regular identifier but is not important enough to be a keyword.
> 
> 
> But then again, what's the big difference between _ and $ in that case?
> 
> Why is:
> 
>> $length
>> $argptr
>> $arguments
>> $file
>> $line
>> $timestamp
> 
> 
> Better than:
> 
>> _length
>> _argptr
>> _arguments
>> __FILE__
>> __LINE__
>> __TIMESTAMP__
> 
> 
> ("length" and "$" are both evil and must be thrown down a cliff,
>  _length is only useful for templates - otherwise use AA.length?)
> 
> I just don't see the point of changing it, into something so similar ?
> But I'm pretty tired of this thread so I'll just wait it out, myself...
> 
>> Furthermore, this approach still leaves quite some room for $ to be 
>> used for other big issues.
> 
> 
> $ @ makes it look like variables to programmers used to shell and Perl, 
> just like the `` strings make it look like it runs external programs...
> 
> I definitely prefer _name, __NAME__ and r"" over these "alternatives".
> Can't say that I plan to use *any* of them in most of the regular code?
> 
> They're all pretty specialized, IMHO. (for Templates/Variadics/Logging)
> *I* think that you should save $ and @ for something else completely...
> 
> --anders
March 13, 2005
Re: $ as prefix (and $len vs, $length)
kris wrote:

> The difference is small but quite significant: '_' is legal within 
> user-identifiers (variables, function names, etc) whereas '$' and '@' 
> are not.

Guess I've just been using C too long. Starting a user identifier
with underscore has always been done at your own peril, as those
used to be reserved for compiler internals (usually macros, there)

However, messing with "length" crossed at least my own boundaries...

> By using a '$' or '@' as a prefix, Walter can happily extend these 'meta 
> tags' without fear of breaking any exisiting code (conflicts in the 
> user-namespace) and without having to create a reserved word.

Well, *theoretically* one could also ban _ from starting user vars ?
(since _arguments and _argptr were there, I thought it was implied)
Anyway, meta tags doesn't sound all bad. Just thought it was overkill.

Until the "next big thing" shows up, I don't think it needs changing...

--anders
March 13, 2005
Re: $; shall we declare time?
On Sat, 12 Mar 2005 08:46:19 +1100, Matthew  
<admin@stlsoft.dot.dot.dot.dot.org> wrote:
> "Kris" <Kris_member@pathlink.com> wrote in message
> news:d0t1vg$9nd$1@digitaldaemon.com...
>> Forgive me, but I didn't see much, if any, criticism of the following
>> which was
>> posted early on:
>>
>> $length
>> $argptr
>> $arguments
>> $file
>> $line
>> $timestamp
>>
>> or the alternative:
>>
>> @length
>> @argptr
>> @arguments
>> @file
>> @line
>> @timestamp
>>
>> 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?
>>
>> Does this point out a problem with NG's in general? ~ perhaps all too
>> often the
>> bigger picture is lost to the winds?
>
> Well, I still think that __FILE__ is a different kind of fish to
> $length, but not so much as I'd be motivated to (further) argue the
> point.
>
> Were the consensus to be that the above $-prefixed list be
> representative of a general strategy for various meta-ish (meta's the
> wrong word, I know, given MP) things, then I can live with it, and we
> can move on to bigger and badder problems.

Count me in. I think the pro's of using a meta prefix of $ or @ outweighs  
the cons.

Regan
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home