Jonathan Lang wrote:
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?
OK: IIRC, this original definition also preceded Sets. So instead of
"$_.keys.sort »===« $x.keys.sort", perhaps this should simply be
"Set($_.keys) === Set($x.keys)", corrected for proper syntax. Heck,
perhaps "$_.keys" and "$x.keys" should _be_ Sets.
--
Jonathan "Dataweaver" Lang
