On 28 Jan 2003, Aaron Sherman wrote:
I'm not sure I recall the sufficient, yet irrelevant technical reasons.
I certainly can't think of anything. It also helps in the case of
objects that are non truly arrayish or hashish:
my SuperTree $foo;
$foo[Munge]; # Returns the node whose
On Tue, Jan 28, 2003 at 12:11:18PM +1300, [EMAIL PROTECTED] wrote:
This may sound like a silly idea but ...
Has anyone considered removing with the syntactic distinction between
numeric and string indexing -- that is, between array and hash lookup?
PHP works this way.
In particular, it would seem that
%foo[$key]
would be just as easy for the compiler to grok as
%foo{$key}
On Mon, 27 Jan 2003 15:39:19 -0800, Damian Conway [EMAIL PROTECTED] wrote:
Sure. But then is this:
$ref[$key]
an array or hash look-up???
Yes, well I suppose that could be
On Wed, 29 Jan 2003 18:04, Michael G Schwern wrote:
On Tue, Jan 28, 2003 at 12:11:18PM +1300, [EMAIL PROTECTED] wrote:
This may sound like a silly idea but ...
Has anyone considered removing with the syntactic distinction between
numeric and string indexing -- that is, between array and
John Williams wrote:
I think you are still overlooking the autovivification behavior.
i.e. What is the difference between these:
1) $a{1234567} = 1;
2) $a[1234567] = 1;
Answer: #1 creates 1 element. #2 creates 1,234,567 elements!
Not currently: 2) does
- generate a sparse hole
--- Sam Vilain [EMAIL PROTECTED] wrote:
=head2 includes( [ Ikeys, ] [ Ivalues ])
Where the keys and/or values are obviously junctions.
if ($container.includes(any(ant, beaver, cow, duck))(
...
This is *SO* cool.
=Austin
On Wed, 2003-01-29 at 05:29, Leopold Toetsch wrote:
John Williams wrote:
I think you are still overlooking the autovivification behavior.
i.e. What is the difference between these:
1) $a{1234567} = 1;
2) $a[1234567] = 1;
Answer: #1 creates 1 element. #2 creates
Michael G Schwern wrote:
On Tue, Jan 28, 2003 at 12:11:18PM +1300, [EMAIL PROTECTED] wrote:
Has anyone considered removing with the syntactic distinction
between numeric and string indexing -- that is, between array and
hash lookup?
PHP works this way.
Well, for some definition of
Damian Conway [EMAIL PROTECTED] writes:
This may sound like a silly idea
It's been suggested previously.
Has anyone considered removing with the syntactic distinction between
numeric and string indexing -- that is, between array and hash lookup?
Yes. We rejected the idea.
In
ECMAscript already tried this.
Bad idea.
If your hash keys happen to look like large numbers (e.g. you
have 7-digit product codes) as soon as you store one of them, it says:
Oh, this looks like a number, so we'll store it like an array and
happily creates a million empty array entries for you.
Sure. But then is this:
$ref[$key]
an array or hash look-up???
Decided at runtime?
Doesn't help if $ref refers to a type that has both hash-like and array-like
accessability. And that will be very common, since all Perl 6 regexes return
such objects.
Damian
At 8:47 AM + 1/28/03, Piers Cawley wrote:
Damian Conway [EMAIL PROTECTED] writes:
Sure. But then is this:
$ref[$key]
an array or hash look-up???
Decided at runtime?
How? People use strings as array indices and ints/floats as hash
indices, and count on autoconversion to Make It
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 8:47 AM + 1/28/03, Piers Cawley wrote:
Damian Conway [EMAIL PROTECTED] writes:
Sure. But then is this:
$ref[$key]
an array or hash look-up???
Decided at runtime?
How? People use strings as array indices and ints/floats as
Dan Sugalski [EMAIL PROTECTED] writes:
At 8:47 AM + 1/28/03, Piers Cawley wrote:
Damian Conway [EMAIL PROTECTED] writes:
Sure. But then is this:
$ref[$key]
an array or hash look-up???
Decided at runtime?
How? People use strings as array indices and ints/floats as hash
On Tue, 2003-01-28 at 11:49, Dan Sugalski wrote:
At 8:47 AM + 1/28/03, Piers Cawley wrote:
Damian Conway [EMAIL PROTECTED] writes:
Sure. But then is this:
$ref[$key]
an array or hash look-up???
Decided at runtime?
How? People use strings as array indices and ints/floats
At 4:17 PM -0500 1/28/03, Aaron Sherman wrote:
Now the question becomes, do you WANT them
for readability?
Given that Larry's answer has been a resounding yes all along, the
technical reasons (Which are, themselves, sufficient) are pretty
irrelevant.
--
On Tue, 2003-01-28 at 16:34, Dan Sugalski wrote:
At 4:17 PM -0500 1/28/03, Aaron Sherman wrote:
Now the question becomes, do you WANT them
for readability?
Given that Larry's answer has been a resounding yes all along,
I'm not sure that this specific case was brought up. I remember Larry
At 5:07 PM -0500 1/28/03, Aaron Sherman wrote:
On Tue, 2003-01-28 at 16:34, Dan Sugalski wrote:
At 4:17 PM -0500 1/28/03, Aaron Sherman wrote:
Now the question becomes, do you WANT them
for readability?
Given that Larry's answer has been a resounding yes all along,
I'm not sure that
On Tue, Jan 28, 2003 at 09:24:50AM -0800, Austin Hastings wrote:
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 8:47 AM + 1/28/03, Piers Cawley wrote:
$ref[$key]
an array or hash look-up???
Decided at runtime?
How? People use strings as array indices and ints/floats as
This may sound like a silly idea but ...
Has anyone considered removing with the syntactic distinction between
numeric and string indexing -- that is, between array and hash lookup?
In particular, it would seem that
%foo[$key]
would be just as easy for the compiler to grok as
%foo{$key}
This may sound like a silly idea
It's been suggested previously.
Has anyone considered removing with the syntactic distinction between
numeric and string indexing -- that is, between array and hash lookup?
Yes. We rejected the idea.
In particular, it would seem that
%foo[$key]
would
21 matches
Mail list logo
