A Layered Event System to Provide Method Extensibility.notes

TITLE OF PAPER: A Layered Event System to Provide Method Extensibility
URL OF PRESENTATION: _URL_of_powerpoint_presentation_
PRESENTED BY: Jim Fulton
REPRESENTING: Zope Corp

CONFERENCE: PyCon 2005
DATE: _date_of_your_conference_here_
LOCATION: _venue_and_room_in_venue_

--------------------------------------------------------------------------
REAL-TIME NOTES / ANNOTATIONS OF THE PAPER:
{If you've contributed, add your name, e-mail & URL at the bottom}

Object extensibility
    Extend objects in a pluggable way
    Structural
        Inheritance
        Adaptation
    Procedural
        (Additional behavior when objects are modified/accessed)
        Callbacks (must register callback)
        Hooks (registration independent of call)
        "template methods" - GOF design pattern
        Events
        (most familiar in GUI systems, but useful in a general way)


Events and subscribers
    Events provide plugpoints for additional processing
        >>> import zope.event
        >>> event = "Something happeed"
        >>> zope.event.notify(event)
    Subscribers respond to events

The Base Event System
    (free of any policy)
    subscribers = []
    def notify(event):
        for subscriber in subscribers:
            subscriber(event)

Adapters
    (simple and general as we use them, the pattern community uses a more narrow definition than we do.)
    You have a certain type, but you want a different type.
    Example: Euclidean points vs. Polar points

Simple adapter application
    We are tightly bound to the Polar class.

Interfaces
    Describe standard ways to hook things together

In our example
    define IEuclidean and IPolar interfaces
    Add implements clauses to Euclidean and Polar implementation
    Polar class adapts Euclidean

Register and Use Adapter
    Q: what happens when you have more than one adapter?

"inheriting" adapters
    Adapters end up behaving like a loose form of inheritance, the way we've implemented them.

Overriding adapters
    More specific subclasses override general superclasses

Subscription adapters
    call many/all adapters rather than one
    Imagine we have documents and various adapters that perform validation:
    [example]
    (for subscription adaptors, we can have multiple, call all of them)
    (main point: with subscribers, you can call multiple objects)

Handler registration and usage
    Have ability to dispatch events based on event type
    We want to use component handle to extend event system.

Adding object-type dispatch
    Extend the system to dispatch based on the type of the object carried by an event.

Instance Dispatch
    Dispatch based on the specific instance being carried by the event.
    You can have any number of handlers that can get called independently.

Zope's event system doesn't support event ordering guarantees (but could be made to do so)
    Use marker interfaces to control event ordering

Related Techs:
    AOP: Aspect Oriented Programming: "pointcuts" - AOP oriented eventing system
    Rule-based systems
        Events tend to give similar effect as if/then rules.
        Could be generalized with predicates, etc.

Summary
    Events poowerful and easy way to extent processing
        Z3 currently uses ~50 subscribers
        our applications provide a lot more
    The basic event system could provide a common way to publish events for Python applications
    Build up policy in layers
        Adaptation provides powerful type-based dispatch

Q: "adapter" instead of "adaptor"
A: thinks "adapter" is right

Q: what advantage over PyDispatcher?
A: not aware of PyDispatcher. Sounds very similar.

Q: Twisted's [?]-system very similar to Zope events, thinking of extending it. [details] adapter-based system would be a lot slower.
A: I don't see any reason why long list of hooks... list of hooks doesn't tend to be all that long. If lower layer doesn't fire, the upper layers don't either. I expect adapter look up speed to become close to method lookup speed. Only the relevant layers fire.

--------------------------------------------------------------------------
REFERENCES: {as documents / sites are referenced add them below}
jim@zope.com

--------------------------------------------------------------------------
QUOTES:

--------------------------------------------------------------------------
CONTRIBUTORS: {add your name, e-mail address and URL below}

Chris Shenton <chris@shenton.org>
Ted Leung <twl@sauria.com>
Abhay Saxena <ark3@email.com>

--------------------------------------------------------------------------
E-MAIL BOUNCEBACK: {add your e-mail address separated by commas }

--------------------------------------------------------------------------
NOTES ON / KEY TO THIS TEMPLATE:
A headline (like a field in a database) will be CAPITALISED
    This differentiates from the text that follows
A variable that you can change will be surrounded by _underscores_
    Spaces in variables are also replaced with under_scores
    This allows people to select the whole variable with a simple double-click
A tool-tip is lower case and surrounded by {curly brackets / parentheses}
    These supply helpful contextual information.

--------------------------------------------------------------------------
Copyright shared between all the participants unless otherwise stated...