At 12:23 PM 8/12/00 -0700, Larry Wall wrote:
>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.
I'm hoping for both. Playing vtable games should help with it.
>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 +.
I don't mind if someone overrides the vtable functions for a variable of a
built-in type--a standard declaration of:
my $foo;
is really shorthand for:
my generic_scalar $foo;
more or less. If a variable gets its vtable functions messed with, well,
that's OK. If + doesn't actually add, well, no biggie. I'd like to have the
optimizer not assume functionality on variables that have been overridden
somehow. (So if $foo gets tied we stop assuming we know what + does, for
example)
The bigger thing I worry about is if someone does something odd like make +
short-circuit, or && not short-circuit. That's the sort of base behaviours
I'd like written in stone someplace.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
