[PEAK] What do you use 'offerAs' for?
Phillip J. Eby
pje at telecommunity.com
Thu Sep 29 21:46:52 EDT 2005
At 05:58 PM 9/29/2005 -0700, Jason wrote:
>I think Dave P sent a mail about one of our uses of offerAs but since I
>don't see it I'll send another.
He sent it privately, rather than to the list.
> Our application has an event system in which the top level app offers
> an event handling class and other components (plugins, widgets, etc) can
> either Obtain it or make their own and offer it to their children.
>This event class it pretty simple, it is where components register signals
>and other observables and it is where other components subscribe to
>them. Creating a new event class basically creates a new event namespace
>for a component and its children. (The event class also knows how to
>propagate events up or down the hierarchy as needed.)
>I'm not sure how dynamic variables could be used in this case. An
>instance of our event class is used across multiple methods in a component
>and I'm unsure how it would be implicitly offered as you described above.
Actually, this sounds more like a case where I'd use generic functions to
specify rules based on component hierarchy, but it's hard to say since I
don't know exactly what behavior is being changed here.
It's also possible to simulate PEAK's current mechanisms with dynamic
variables, by taking a snapshot of the dynamic context when a component is
created, and switching back to that snapshot whenever you create child
items. Not that I'm saying that's better than the current mechanism, just
noting that the dynamic variable API can be used to emulate the current
behavior, but the current system can't emulate dynamic variables except in
a very crude and limited way. Yet, dynamic variables are *much* simpler in
implementation than the current PEAK mechanisms for configuration, so in
the long run I think they will win out.
In all honesty I'm thinking about creating a new development branch for
PEAK - let's call it PEAK 0.6, or maybe be really bold and call it the 1.0
branch. Most of PEAK is about as far advanced as it's going to reasonably
get, in that from my current perspective I can see that it mostly consists
of attempts to work around the absence of far simpler machinery. It's
interface/adapter based, when the few things that have moved to generic
functions are immensely simpler (note last year's peak.security
refactoring). The model system and parsing machinery are kludgy, based on
assumptions filtered through from TransWarp.
Looking at what's *right* with the existing code base, however, yields some
interesting perspectives. The binding framework has two very solid ideas:
* Attribute bindings
* Attribute metadata
For the most part, however, component hierarchy is a bust outside of GUI
applications, where PEAK's hierarchy is going to inevitably duplicate the
hierarchy mechanism of the GUI. (Luckily, more recent versions of PEAK
allow you to easily extend 'binding.getParentComponent()' to work with
The whole hierarchy thing for me actually came from an early set of
assumptions baked into TransWarp, that 1) web applications were going to
use the component hierarchy, and 2) it would be good for GUIs too. It
sounds like it has worked out well for GUI's, and it is in fact helpful for
web apps, too, but in both cases I think there are ways to use simpler
tools to do the job. In the case of web apps, there's a natural pattern of
calling "down" the hierarchy, such that dynamic variables work perfectly,
and in "bubble-down" GUI event systems it should work well too. Bubble-up
GUI systems, on the other hand, would likely use a generic function for
event handling, with rules added using a precedence system that matches the
Anyway, the flaw of PEAK's component hierarchy system is not so much that
the idea doesn't work. In fact it works quite well, up to a point. I
think PEAK carries it just a little beyond that point, which results in
more complexity for the *developer* as well as for the implementation. You
have to end up caring about all kinds of stuff that the dynamic variable
approach doesn't have, like your assembly events, making sure there's a
configuration root, etc. These things are pretty easy to do, but then
there's that old saying that "no matter how good your interface is, less of
it is better."
Another unexpected innovation that strikes to the heart of the current
implementation assumptions, is setuptools' entry points. If I were
designing peak.naming today, I would definitely tie URL schemes default
handlers to entry points, for example. Heck, there are lots of things I'd
use entry points to establish defaults for. For that matter, you shouldn't
have to get people to glue something into their sitewide PEAK configuration
file in order to use plugins of any sort. Just get the egg on sys.path,
and its feature(s) should be available.
If I were to start a new branch of PEAK on this basis, I'd probably also
want to make some progress on chopping out all the separately-distributable
bits that aren't married to the current core. Mostly that'd be peak.util.*
stuff, though, which is almost all mature and lacking only in sufficient
Anyway, I'm rambling on at this point. I don't know exactly how I'd
prioritize these efforts, because I don't have a "customer" for any of them
at the moment, and I sort of want to do *all* of it. I've been spending
some cycles on peak.schema recently, or at least the design of it, but I'm
also torn between doing dynamic variables, more generic function polishing,
working on SCALE, etc.
More information about the PEAK