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?
