[1072] in BarnOwl Developers
Re: Rethinking ::Hook
daemon@ATHENA.MIT.EDU (Nelson Elhage)
Thu Oct 29 18:12:43 2009
Resent-From: nelhage@mit.edu
Resent-To: barnowl-dev-mtg@charon.mit.edu
X-Original-To: nelhage@nelhage.com
Date: Sun, 18 May 2008 21:02:32 -0400
From: Nelson Elhage <nelhage@MIT.EDU>
To: Geoffrey G Thomas <geofft@mit.edu>
Cc: barnowl-dev@mit.edu
In-Reply-To: <alpine.DEB.1.10.0805171559340.32029@vinegar-pot.mit.edu>
Currently, modules aren't really treated as classes at all. We could
change that, but I worry that down that road lies Eclipse and Java.
I think I do want to have a hook solution that doesn't require being a
class to use.
- Nelson
On Sun, May 18, 2008 at 04:45:50AM -0400, Geoffrey G Thomas wrote:
> On Sat, 17 May 2008, Nelson Elhage wrote:
>
>> 1. Have modules register a function name as a string, rather than a
>> subref. This has the property (not always good) that if the code
>> changes but the hook doesn't get re-registered, the new hook takes
>> effect.
>>
>> 2. Use Sub::Identify or similar to ask perl what function the
>> subroutine represents, and filter the hook list to remove any other
>> function of that name.
>>
>> 3. Use caller() to figure out which module is registering this hook,
>> and only de-register hooks for a specific module before reloading
>> that module
>>
>> 4. Have modules provide a string "name" or identifier for each hook
>> they register, and remove handlers sharing the same name.
>
> I don't understand Perl OO too well, but is there something like an
> abstract class method that we can ask modules to implement if they wish
> to add a hook? This avoids any outside dependencies on the naming scheme
> of internal functions, and potentially of modules as well....
>
> --
> Geoffrey Thomas
> geofft@mit.edu
