Garrett Goebel <[EMAIL PROTECTED]> writes: > From: Piers Cawley [mailto:[EMAIL PROTECTED]] >> Garrett Goebel <[EMAIL PROTECTED]> writes: >> > >> > And what's to prevent that collection object from handling: >> > >> > my $queue = SomeQueue.new; >> > >> > $queue.push('foo'); >> > $queue.push('bar'); >> > $queue.push('baz'); >> > >> > my $index_of_foo = $queue['foo']; # undef if no foo in queue. >> >> Because I also want to be able to access >> >> $nth_foo = $queue[$n] >> >> Which I thought was so blindingly obvious as not to need stating. > > Never underestimate blindingly obvious when I'm involved ;) > > $idx_of_foo = $queue['foo']; # named lookup > $nth_foo = $queue[600]; # ordered lookup > > One is SvPOK the other SvIOK... > > Can't we handle both and still have the ordered lookup be fast?
No. Because in general we don't know what's in the brackets until runtime. And then we don't know in what context to evaluate what's in the brackets. Because, in Perl unlike in many other OO languages that don't have a syntactic distinction between array and hash lookup, a value can happily have both a numeric *and* a non-numeric value. Which means that YOU CAN'T USE THE TYPE OF THE 'INDEX' OBJECT TO DETERMINE WHETHER YOU'RE DOING A HASHLIKE OR AN ARRAYLIKE LOOKUP. As Dan pointed out ages ago. The only reason I suggested that it didn't matter was because I'd forgotten about the cases where having both arraylike and hashlike behaviour was useful. -- Piers
