On Tue, Apr 12, 2005 at 06:58:29PM +0300, Yuval Kogman wrote:
: We blitzed a discussion on #perl 3 minutes ago, reaching the
: conclusion that negated subscripts are cool.
: So i was thinking:
: subscripts are objects.

I'm all in favor of powerful constructs, but we need to be *really*
careful not to compromise the visibility of ordinary integer
subscripting to the optimizer.  At one time we proposed that a
subscript could be either an ordinary slice or any selector that
could be smartmatched against the available indexes, but lately we've
been leaning toward the idea that subscripts are simple slices of
integers, and there should probably be an explicit method syntax to
tell the compiler to pessimize calls to fancy selectors.  As they say:
"Optimize for the common case."  And the common case here is integer
subscripting, by far.  That's basically all that distinguishes .[]
from .{}, after all (plus a bit of type checking).

Interestingly, if .{} defaulted to smart matching, ordinary .{'foo'}
would essentially fall out of the samantics of "find me all the keys
that smartmatch "foo", which is only one of them, presuming a hash
that guarantees uniqueness.  One could view .{} as Perl's version of
SQL's "select".

It could be argued that the same optimizability concerns apply to
hashes as well as arrays, but hashes are already bound into a fairly
heavy set of semantics, so going to the most general semantics via
MMD might not actually cost us much.  It might not cost us anything,
if general hash lookups have to go through MMD anyway.


Reply via email to