Dan Sugalski writes:
: Yup. It's an issue for things that implement any non-standard semantics for
: existing ops, especially if those ops are overridden at runtime so the
: optimizer doesn't know. It's one thing to mess with tied variables, its
: another entirely to make + behave differently.
:
: I think we'll need to get a ruling from Larry at some point on this one.
I haven't been terribly happy with tie for some time. I'd rather we had
more type-based approach, which could:
1) factor the work out to one spot so you wouldn't have to call tie
on every element of an array, for instance.
2) let us tie lexically scoped variables that don't leak out to the
surrounding program.
And even if we keep the current tie interface (and we probably have to,
even if we add a better way), we can probably limit the damage other
ways. If we see a declaration like:
my int $foo;
we can decide either that $foo will never be tied, or that it will never
be tied to an implementation that violates the standard meaning of +.
Larry
