Front page | perl.perl5.porters |
Postings from September 2010
Ben Morrow wrote: >'Cause that's what the spec says :). PRE and POST assertions are >inherited, for method calls only, Is this something being copied from Perl 6? In the Perl 5 world, I'd be a lot happier with the method definition specifying whether it's a method, and PRE/POST behaviour being keyed from the definition rather than the use. We already have ways to intensionally distinguish methods from functions, such as the "method" keywords supplied by the various ::Declare modules. They should probably be applying the core's :method (CVf_METHOD) flag, which is currently little used because it has almost no effect in the core. >I would have though the existence of Devel::Caller::called_as_method was >enough to demonstrate this is useful elsewhere, as well. As you described it, called_as_method is an excreable hack that doesn't remotely achieve what the name suggests. I'm not inclined to treat it as any kind of demonstration. It might be illuminating to look at the things that currently try to use it, though. >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? It's much more qualitative than that. Functions and methods aren't just blurred, they're *completely equivalent*. It is a feature of the language that a method call constitutes (a) looking up the appropriate method implementation for the invocant and then (b) calling the implementation function with the invocant as its first argument. The two phases are commonly separated, to varying degrees, and the fact that the second phase is precisely an ordinary function call is both an established protocol and very useful. The question before us is whether to introduce a completely new runtime distinction between two kinds of function call. Effectively, a new flag that all callers need to set correctly. Look how well that worked with the UTF-8 flag. In this case, it's not just XS code that needs to change for the new flag, it also affects pure Perl code that performs the second phase of a method call by the use of function call syntax. >> 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? If this distinction, a new flag attached to every function call at runtime, is to be added to the language, then yes, the ability to read that flag needs to be added to the language's stack introspection facility. I'm not averse to it being yet another item (the twelfth) on the returned list. I'd also be happy with some kind of move towards a hash of named items, but I think it would be better to go that way using a new caller-like interface that *only* returns a hash, rather than changing caller to return a hybrid format. -zeframThread Previous | Thread Next