Larry Wall wrote:
Jonathan Lang wrote:
: Looking through the table provided, I ran across the following:
:
: $_ $x Type of Match Implied Matching Code
: ====== ===== ===================== =============
: Hash Hash hash keys identical match if $_.keys.sort
: »eq« $x.keys.sort
:
: My understanding is that at the time this was written, the working
: theory was that Hash keys would always be strings. I'm wondering:
: should this entry replace 'eq' with '===' or 'eqv', so that non-string
: keys can also be compared for equivalent values? If so, which
: operator should replace 'eq'? (I'm leaning toward '===', since S03
: defines '$a eq $b' as '~$a === ~$b'.)
Yes, it should be ===. But in revising the smartmatching tables for this
and other ===nesses, and thinking about how hashes may or may not be
implemented as ordered underneath, it seems to me that .keys.sort is
suboptimal if sort has to second-guess the ordering provided by the
underlying hash.
Not only is it suboptimal, it might not be possible. Sorting depends
on cmp returning Order::Increase, Order::Same, or Order::Decrease in
every case; but what if you're comparing Color::Blue to Bool::True?
And what about classes that involve partial ordering, such as sets?
Heck, how do you '[cmp] Color::Blue, Color::Gray', and what does
"sqrt(-1) cmp 0" (or even "sqrt(-1) <=> 0") return?
--
Jonathan "Dataweaver" Lang
