Damian Conway <[EMAIL PROTECTED]> writes: > Uri Guttman wrote: > >> but what simon was saying (and i agree) is the the pair IS a single >> item. it becomes the key and its value is 'scalars'. > > No. If it's a PAIR, then its key is the key and its value is the value. > > >> hashes can now take objects as keys and won't just stringify them. > > Correct. But I believe that's only if the hash has a property that marks > its keys as being objects, not strings: > > my %hash is keyed(REF); > > And, even if that's the default, it still oughtn't apply to PAIRs. > To get keys that are PAIRs, you should have to say: > > my %hash is keyed(PAIR);
I really hope you're wrong about that last one. Or are you really proposing that, given C<my %hash>, one can't do C<%hash{$arbitrary_object} = $value> and get back the 'real' C<$arbitrary_object> from C<%hash.values>, that seems to run counter to what's been said about perl6 hashes. Requiring C<is keyed(REF)> seems kludgy, but 'is keyed(PAIR)' for anything but optimization or 'contract' stuff seems Bad And Wrong. >> @array = ( key => 1, key2 => 3, 4, 5 ) ; >> %hash = @array ; >> what does that do? 3 pairs in the hash or 2 (the first pair is the >> key >> for the second pair)? > > Three. As above. You'd get: > > %hash{'key'} = 1; > %hash{'key2'} = 2; > %hash{'4'} = 5; I'm not sure I agree. If you're going to make it behave like that then at least allow us to do something like %hash = @array but no_special_pairs; (Not sure that's a good property name, but it's the best I could come up with at the moment.) > > there needs to be some semantic way to select the hash assignment style > > C<is keyed()> No; that puts the property in the wrong place. -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?