in reply to subclass or hooks?

How do you expect your classes to be used? That's the big difference between the two approaches.

The first approach requires that I, your user, write a new class, test the whole class, and go forward from there. Lots of Perl knowledge required.

The second requires that I, your user, write a funciton and pass the subref to you in some constrained fashion. Less Perl knowledge required, but slightly messier design (from an imperative standpoint).

I personally prefer the second approach, because it's a better design for what you want to do. The extra time in design is well-worth the effort, IMHO.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Replies are listed 'Best First'.
(tye)Re: subclass or hooks?
by tye (Sage) on Nov 21, 2001 at 02:02 UTC

    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")
[reply]
      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