Front page | perl.perl5.porters |
Postings from September 2010
Quoth zefram@fysh.org (Zefram):
> Ben Morrow wrote:
> >These patches record whether a given stack frame is for a function or a
> >method call, by adding a new OPpENTERSUB_PRIVATE bit. I need this for
> >PRE and POST blocks, which have different behaviour depending on whether
> >a sub is called as a method or not.
>
> Why do you need behaviour to differ based on this?
'Cause that's what the spec says :). PRE and POST assertions are
inherited, for method calls only, so I need to know if this is a method
call or not (since Perl 5 doesn't distinguish at compile time).
I would have though the existence of Devel::Caller::called_as_method was
enough to demonstrate this is useful elsewhere, as well.
> I'm dubious about
> breaking the equivalence between $foo->bar and $foo->can("bar")->($foo);
> plenty of code relies on it.
This is really the important question: do we want to keep blurring the
line between function and method, the way Perl 5 always has, or do we
want to sharpen it up a bit? IMHO making it possible to cleanly make
the distinction is a good thing, and the problems with code that has
been making not-method calls will sort themselves out over time.
It's not as though any behaviour changes, except that code relying on
Devel::Caller::caller_as_method suddenly starts working better than it
did before. Choosing to rely on the distinction is entirely up to those
writing code that does that. Putting the flag in the core just means 1.
it works properly and 2. we are tacitly accepting this is a valid
distinction to make.
> If you really do need to make them inequivalent, then the flag should
> be available through caller().
Do you think it's worth it? And where would you put it? Yet another
return value?
> And G_FAKINGMETH is improperly derogatory: performing a method call
> through call_sv() is no more fake than $foo->$methodref.
Yes, it is. call_sv *without* G_METHOD is $method->($obj, @args)
(there's no OP_METHOD(_NAMED)? involved at any point). call_sv *with*
G_METHOD is $obj->$method(@args), but won't accept a bare CV (only a
cvref). My next step was going to be to remove G_FAKINGMETH again, by
allowing pp_method to accept a bare CV, and possibly consider removing
OP_METHOD(_NAMED)? altogether, but I wanted to have the discussion about
whether this was a good idea at all first.
As for 'derogatory', I was emulating G_FAKINGEVAL, which does something
rather similar.
Ben
Thread Previous
|
Thread Next