--- Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 8:47 AM +0000 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 Work.
On the one hand: Java/ECMA/J-script does it. All objects are associative arrays. All arrays can be associative, on demand. C<a["foo"] = 1;> Presto. Associative array. On the other hand: This gets dangerous really quickly, since Perl's autoconversion works differently. Specifically, since we treat things as "strings unless they need to be otherwise" rather than treating them as "the type that they were when you created them". (Javascript doesn't have much in the way of I/O, so the act of getting data in is a bit of an effort, and that effort usually has the side effect of providing type data.) Writing a roulette game may get challenging: @colors["0"] = Green; @colors["00"] = Green; @colors["000"] = Green; Do those get autoconverted to numbers? (They can, obviously. But they shouldn't.) This kind of thing points back at a discussion we had once before about "more kinds of context" -- meaning at the time "numeric" versus "string" versus ... whatever. I think that if we do this we'd better know more about what we're expecting versus what we're losing. On the "losing" side, the difference between lowercase-array and lowercase-hash is probably significant, performance-wise. Merging the array and hash notions may cost a lot of speed for a lot of people. On the "gaining/expecting" side is ... what? Freeing up curly braces? Improving the syntax? Other stuff not obvious to me right now? If we go that route, we could certainly include a new "pure array" type: my @trough = slop(); my PureArray @pa = ducks(); my PureHash @ph = dictionary(); =Austin
