At 12:48 PM 8/13/00 +1000, Jeremy Howard wrote:
>Dan Sugalski writes:
> > 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.
> >
>Would that really be a problem? Damian is writing an RFC that will propose
>allowing '?' in a function prototype to indicate a lazily evaluated
>parameter. If someone overloaded C<+> with a function that had a prototype
>where the 2nd parameter was evaluated lazily, couldn't Perl notice this and
>do the right thing?
Yeah, but we can't guarantee that the function doing the overriding is one
written in perl. (Tying and overriding may share an underlying
implementation, though I'm not sure yet)
Regardless, we can't always tell at compile time if a variable is tied or
not, so we'd actually need to have both code paths available with some sort
of 'ifweird' opcode that chose the path based on the variables involved.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
