Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

TorgoX (1933)

TorgoX
  sburkeNO@SPAMcpan.org
http://search.cpan.org/~sburke/

"Il est beau comme la retractilité des serres des oiseaux rapaces [...] et surtout, comme la rencontre fortuite sur une table de dissection d'une machine à coudre et d'un parapluie !" -- Lautréamont

Journal of TorgoX (1933)

Friday March 08, 2002
12:42 AM

Handler objects

[ #3373 ]
Dear All,

There seem to be main three kinds of modern interfaces for events:

  1. You specify eventname1 => CODEREF, eventname2 => CODEREF, ... in a call to something, thereby declaring those as the handlers.
  2. You subclass the main class, and provide override methods sub eventname1 { ... } sub eventname2 { ... } ...
  3. You provide an object on which can be called $object->eventname1(...), $object->eventname2(...), ... and that object need not be a subclass of anything specific.

Now, my question is: does anything but SAX use style 3 there?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • POE's object_states are very similar to how SAX works.
  • I do... (Score:1, Insightful)

    Who the hell cares what your object inherits from so long as it provides an appropriate interface in whatever context. Formalizing the interface concept is nice if you're a compiler, but can be a pain in the arse if you're a programmer. And if you get the interface wrong the program will die early with a sensible error message, so everyone's happy.

    Taking this approach helps a great deal if you start looking at techniques like mock objects for testing, or facade type objects that delegate everything.

    Don't
  • SAX uses both 2 and 3. It uses 2 for drivers and filters, and 3 for simple handlers.

    The reason this was so is totally deliberate: the most common case in SAX is a handler. With that approach, you only need to provide a (possibly fake) constructor and define those handlers you need. That could have been achieved using approach 2, but that might have gotten in the way of filter chains.

    As for other examples of the same pattern, many GUIs and MVC approaches use it. I've seen it on many an occasio

    --

    -- Robin Berjon [berjon.com]

  • Style 3 is Java interfaces. I loved the concept when I first heard about them, but apparently most older books don't focus on them. (Apparently Java, like Perl, has a huge backlog of obsolete information, advice, and books floating around out there.) I guess interfaces made it into SAX via Java.

    Basically, an interface is like a virtual class, except there's no inheritance involved. Interfaces can be used to give you the benefits of multiple inheritance without actually allowing such. For example, to

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
    • Yes, that's very close to the idea. And in fact, there's a growing number of classes that implement the SAX interface while not having SAX as their central focus. They just want to be usable as SAX handlers to build their internal structure.

      The way we did it is however slightly different as you are not forced to implement anything of the interface. In fact, you could provide any object as a SAX handler and it will still work, even if it implements none of the interface (quite simply, nothing will

      --

      -- Robin Berjon [berjon.com]