Michael G Schwern wrote:
>
> Okay, this is the FIRST TIME I've ever seen indirect object syntax
> used for anything useful. (That's praise, BTW)
Thanks. :-) Encouragement is always appreciated.
> Its not slow. ITS SLOWER THAN MOLASSES ON A COLD DAY ON PLUTO!
Well, I didn't want to be mean... ;-)
> It may make sense to pass a leading argument to TIE which is the type
> of variable being tied.
>
> tie Some::Class $foo, @args;
>
> would produce:
>
> TIE('SCALAR', 'Some::Class', @args);
Great idea. That way your TIE() method could decide what to do. Maybe it
would tie hashes and arrays the same, but reject scalars. Plus it's more
flexible in the event that other types are added or this is used for
typecasting.
> BTW Should C<Some::Class->tie($foo, @args)> work or would it be
> Some::Class->TIE($foo, @args)? Or both? Or neither?
Some::Class->tie($foo, @args)
Would work, since it will inherit from UNIVERSAL::tie (actually, either
would work syntactically, but ->TIE will bypass UNIVERSAL::tie, which is
needed to do all the special under-the-hood stuff, sort of like calling
->DESTROY directly ("Are you sure you wanted to do that?")).
> True, but I don't believe this is the real reason for the
> inefficiencies. You might want to ask on p5p for a detailed set of
> reasons why tying is inefficient. I think some of it has to do with
> oddities in the implementation.
Yeah, I'll check. I think you're pretty much correct in your analysis,
but I'll definitely get clarification on this.
> > # Include tied interface
> > sub TIE {
> > my $self = self; # RFC 152 :-)
> > bless {@_}, $self;
> > }
>
> Ya know, this almost points out a weakness in RFC 152. Why have a
> self keyword if you're immediately going to assign it to a variable???
> Perhaps it was just from habit.
Yeah, there's no reason that the above couldn't (shouldn't?) be written
as:
sub TIE {
self->bless {@_}, self;
}
Assuming RFC 152 is adopted. Now whether it'll be named self(), this(),
$ME, $INVOCANT, or something else is still being debated (but again,
let's discuss this elsewhere).
> Again, I think the issue of translation is a red herring. I believe
> the problem to lie elsewhere. Ask on p5p and try compiling perl5 with
> gprof to see where the problem is.
Sounds good. Thanks again for the great feedback.
-Nate
