[PEAK] Re: Binding fever

[Phillip J. Eby]

At 09:49 AM 11/3/03 -0800, John Landahl wrote:
>By the way, regarding your question about "binding fever" -- I definitely 
>have it, but I don't know if it was related to the changes in the API.
>Perhaps.  It definitely simplifies things, and using it feels really 
>streamlined now.  Especially now that the full 's, d, a' parameters are no 
>longer required -- that's made a *big* difference to me somehow, again, 
>more in the way it feels to use it.  BTW, how did you manage that trick?
>Do you try calling the method with "s, d, a" first, then just "s", then no 
>parameters?  Or is there a way to determine a callable's signature through 
>introspection?

Introspection.  Check out peak.util.signature and peak.binding.once for the 
dirty details.  Also, note that using an 's,d,a' signature actually runs 
faster at the moment, because there's two levels of function call taking 
place.  But of course that's probably a miniscule overhead compared to 
whatever the Make() call is actually doing at that point.


>I was also wondering if there were any specific inspirations behind the 
>binding library.  Are there any other languages or libraries out there 
>that have similar features?

Yes, lots.  But none are so cleanly integrated, IMO.  Haskell has lazy 
tuples that do the once-and-immutable computation.  Eiffel has the concept 
of "once-functions", although they work at a class level.  Java's 
PicoContainer has the idea of supplying collaborators to a component via 
its constructor, based on required interfaces.  The ObjectTeams system uses 
an adaptation-like mechanism coupled with one-time computation, to connect 
collaborators.  Java has lots of "container-oriented" frameworks.  And on 
and on it goes...  lots of systems have things that are "sort of" 
similar.  Really, about the only really new things that PEAK adds are to 
make every component coupling able to both 1) have a default 
implementation, and 2) be overrideable by the creator.  (And I'm not 
positive that you couldn't say JavaBeans doesn't have such a capability, 
especially if you're scripting them with Jython, where keywords passed to a 
constructor map to setWhatever() calls.)

However, PEAK does includes the best features from a great many component 
systems, including parent component autodiscovery, assembly 
events...  binding by name, key, or interface, factory functions...  yeah, 
I guess I went for a helping of everything from the component architecture 
buffet.  :)


>   It feels like a whole new way to program,

It is.  But it's what's been being called the holy grail of programming: 
programming with truly reusable components.  But the problem with component 
programming was never the components themselves.  It was always in the 
*wiring* and *connecting* of components that made them hard to reuse, or 
even use in the first place.  You could sort of say that the peak.binding 
motto is, "Compose, Configure, Connect", as these are the key requirements 
for a solution-domain component architecture.


>and the other programmers I've exposed to PEAK have been having a hard 
>time "getting it".  Though one who had been helping out with my project 
>for a while, and so had been exposed to binding for a while now, just said 
>the other day that he's starting to see what I'm so excited about.  Maybe 
>it's the streamlined API, or maybe it's a matter of it needing to sink in 
>over time, or maybe it's a bit of both.

Probably.  I seem to have a habit of creating these sorts of paradigm 
shifts.  Usually in the form of popularizing or refining a concept first 
promoted by Jim Fulton.  Really, some aspects of peak.binding are just 
type-safe, explicit forms of what you can do in principle with name-based 
acquisition.  (You just don't really *want* to do them that way.)


>I've been writing up a bunch of notes about binding and PEAK in general, 
>and will be adding more to the DevCenter shortly.  I did make a few minor 
>updates recently, like adding a page for a glossary and adding some brief 
>overviews to the main page.  I think the glossary is going to be 
>absolutely crucial, since there are many unique terms in PEAK, or terms 
>where some explanation up front will go a long way toward furthering 
>understanding for a new PEAK user.
>
>Have you considered writing a book about PEAK?  Perhaps something like 
>_Python Enterprise Development with PEAK_...  It would make a great 
>O'Reilly title.  :)

Well, I think the software would need to be a bit more finished first.  And 
then, the first thing I'd be writing would be the *manual*.  I'll let 
somebody else get the fame and fortune of the book deals.  (E.g. somebody 
who's still under the impression that you can get fame and fortune by 
writing a technical book, especially on a non-buzzword language and 
product.)  ;)