Leopold Toetsch <[EMAIL PROTECTED]> writes: > Piers Cawley <[EMAIL PROTECTED]> wrote: >> Leopold Toetsch <[EMAIL PROTECTED]> writes: > >>> Just use a Key PMC for $P2. > >> So, just for fun I added the following test to t/pmc/perlhash.t: > >> new P10, .PerlHash >> new P1, .PerlString >> set P1, "Bar" >> new P2, .Key >> set P2, P1 > ^^^ > > C<set Px, Py> aliases the two PMCs, both are pointing to the same PMC > then. You'd like to use C<assign> here.
Of course I would. Oops. > >> new P3, .Key >> set P2, P1 > ^^ > typo? Yes, and should be an assign. >> Perl 6 supports using full on objects as keys in its hashes. It seems >> that having parrot do the same would be a Good Thing. > > The main problem here is, what does ... > > set P0, P1[P2] > > ... mean: keyed_string or keyed_integer, i.e. hash or array lookup. > The Key PMC provides this information, a plain string could be used in > both ways: > > set P2, "42" > set P0, P1[P2] > > It depends of course on the aggregate, what kind of key it would like to > use, but e.g. for an OrderedHash PMC, which supports lookup by string > *and* by integer, the usage is ambiguous. I'm not advocating removing the key object for disambiguating this sort of thing. > We could change C<key.c:key_integer()> to extract a number with > C<get_integer> from any PMC and do the same with C<key_string> but some > keyed usage needs a defined type. I'd argue that at the base level all objects should have a 'hash_int' method (or some other name to be decided) which generates a hash integer appropriate to the object. See countless smalltalk images for such usage.
