Thanks for the feedback Uri.
Some specific points:
> PRL> pre tax_payable_on {
> PRL> $_[0] -= 20.00; # routinely underquote sales price
> PRL> }
>
> i assume like normal subs, that changes the original argument in the
> caller.
Correct. Guess I'd better clean up that sample code accordingly. ;-)
> what about splicing new values in/out of @_? is that allowed?
I would imagine so.
> i can see passing in things which get deleted/expanded if they are
> in a different format than the primary expects.
Good application. I might include an example of that.
> PRL> pre Cafe::Bar::, sub { print "calling some method of
> PRL> class Cafe::Bar" };
>
> PRL> installs a prefix handler that will be invoked whenever I<any>
> PRL> subroutine from package Cafe::Bar is called.
>
> can you have a package level pre and also a per sub pre? do they
> both get called or does the sub one only get called?
You can have both. They both get called.
> so the handlers are attached to the primary code ref?
Or the primary *name*, depending on how the C<pre> is specified.
> how does this work with package level ones then? all subs must
> check for pakcage level pre before they can be called? this sounds
> like a big slowdown.
No. I imagine that the specification of a package-level handler would
retrofit that handler to each existing sub in the package *and* set a
flag within the package that would cause any sub subsequently defined
in the package to also be given the handler. Apart from run-time
typeglobbing tricks, it would all happen once, at compile-time.
> PRL> =head2 Installing C<post> Handlers
>
> why the separate docs for post and pre syntax? without double checking,
> i assume they have the same syntax other than pre/post. folding these
> into one section would make this easier to digest.
I obviously thought differently. :-)
And, anyway, I don't have time to rejig it :-(
> PRL> =head2 Logically Identified Handlers
>
> this is getting a little ugly and too much IMO.
And yet, it's one of the things people want most from such handlers.
> PRL> =head3 Accessing named handlers
>
> why not just use a single list? the short anon hashes are useless
> there.
No. Suppose my module needs to play nice with another -- say the LastOpen
module shown in the RFC. In that case it needs to know whether that last
handler has the logical name 'LAST', in which case it installs it's own
handler *second* last.
Remember that directly futzing with the handler list should be only very
rarely done. In the vast majority of cases, the automatic "prepend
C<pre>'s, append C<post>'s" behaviour will suffice, provided there is an
easy way for each module to access (at a later time, and regardless of
the installation sequence) the handler it has defined. Logical names
give precisely that functionality.
> it is amusing how most of us don't want SQL/DBMS stuff like NULL in perl
> (myself included) but trigger like stuff like your handlers seems ok.
> for one thing, this is not hard to describe in basic terms (until you
> get to the inheritance stuff) and it is useful in many ways. maybe you
> should rename this as triggers as handlers have a meaning is signals and
> in event callbacks.
I think the term "triggers" is too obscure. "Handler" is a very general
term that people understand in many contexts, apart from signals and
callbacks.
Thanks again,
Damian
