[PEAK] What do you use 'offerAs' for?

[Phillip J. Eby]

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 
non-PEAK types.)

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 
hierarchy.

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 
documentation.

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.