On Thu, Nov 16, 2006 at 04:25:30PM -0800, 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. So maybe we have some or all of:
.keys .sortkeys
.values .sortvalues
.kv .sortkv
.pairs .sortpairs
Possible variations: .skeys, .ordkeys, etc. Also could flip the
default and make .keys sort by default and then you use .rawkeys to get
unordered--shades of PHP. (Note that arrays are already considered
to be ordered when you use these methods.) Or we stick with the
methods we have now and give options for sorting and selecting as
parameters to .keys etc. In any case, making these methods able
to sort allows sorted .kv lists, which would not be possible with
.keys.sort. It also allows the hash or array itself to specify the
ordering behavior declaratively, and perhaps optimize ordering in
various ways that .keys.sort can't do without cheating.
Slicing modifiers like :kv and :pairs could also take an optional
sort parameter, presumably.
Larry
