in reply to Re: subclass or hooks?
in thread subclass or hooks?

But if the number of hooks being specified gets large, then the other approach can be easier on the module user. So I say "Why not both?".

For example, for each "hook" you could provide a default method that calls the user's hook if one has been specified, otherwise does the default processing. Then the user could override the hook either by registering a callback with the object or by defining a new class and overriding that method.

        - tye (but my friends call me "Tye")

Replies are listed 'Best First'.
Re: (tye)Re: subclass or hooks?
by fokat (Deacon) on Nov 21, 2001 at 03:07 UTC
    Better yet, the hooks themselves might be implemented in a subclass. I did this once in a project, and it worked beautifully.

    Applications were born as functions passed to a ...::Callback class. If the applications were used by many people or grew on popularity, they could become modules very easily. This also allowed for improved tests and better Q&A overall.

    Just my $0.02 :)

[reply]
      I find your description somewhat unclear.

      The only thing I have done which kind of fits your description is that I have written code with hooks that are available by subclassing, and then I exported a utility function which could be used to take a few desired callbacks and write your class for you. This worked well because providing hooks through subclassing was a natural implementation, but it was cumbersome to write lots of little subclasses that were all mainly the same, so I did away with the boilerplate.

      Is that what you are talking about? If not then could you explain a little more verbosely, possibly with some code examples for how one would use your interface?

[reply]

In Section Seekers of Perl Wisdom