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.

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

"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

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

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

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

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

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

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

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