March 11, 2005
> I was also pretty sceptical about the usefulness of $/length/whatever. Then I started grepping around to write a post about how silly the feature is and I realized it is more common than I thought. It seemed like about 1/3 to 1/2 of indexing expressions would involve the length.

Hmm. I don't know which grep I was talking about there. The numbers weren't
that high. I think it was a majority of those involving "length" but I don't
think I grepped for all indexing expressions.
Anyway, I got the data from the CIA so it must be right ;-)


March 11, 2005
"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 11, 2005
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
>

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

Jon


March 11, 2005
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 11, 2005
On Sat, 12 Mar 2005 07:45:12 +1100, Matthew wrote:

> "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,
No.

> and we should, now, move on to more significant flaws in the language.
Yes.

> I say we all give Walter a hearty slap on the back for moving to the try-it-out paradigm,

Absolutely!.

> and declare this first one a success (albeit that it's a success in the negative).

No.

-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
12/03/2005 8:20:15 AM
March 11, 2005
On Fri, 11 Mar 2005 21:18:40 +0000 (UTC), 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?

Because they add a more consistent approach to the whole issue, I'd add my support to this type of approach.


-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build
12/03/2005 8:24:58 AM
March 11, 2005
Derek Parnell wrote:
> On Fri, 11 Mar 2005 21:18:40 +0000 (UTC), 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?
> 
> 
> Because they add a more consistent approach to the whole issue, I'd add my
> support to this type of approach.
> 
> 

I like this stuff, too.

Lars Ivar Igesund
March 11, 2005
In article <d0t1h6$4og$1@digitaldaemon.com>, Jon Andrew says...
>
>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
>>
>
>Aye, typing out arr.length really isn't such a big hassle anyway, is it?
>
>Jon

Nope - it's not.

The shorthand notation was introduced to help with templates, where having a 'tmp' for the addressed array is just not convenient. Thus, the implied 'length' was born. It is but for that purpose only, and just happened to provide for a shortcut in other ways. Would have been great other than the problems it caused :-)

Frankly, I'm more concerned about the other tags (such as _argptr, __file__,
etc)


March 11, 2005
"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.


March 11, 2005
On Sat, 12 Mar 2005 08:46:19 +1100, Matthew 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.

Okay by me.

-- 
Derek Parnell
Melbourne, Australia
12/03/2005 8:57:45 AM