[PEAK] Re: Binding fever

[John Landahl]

On Mon, 03 Nov 2003 13:16:52 -0500, Phillip J. Eby <pje at telecommunity.com> 
wrote:

> Yes, lots.  But none are so cleanly integrated, IMO.

 From what I know of the examples you mention, I'd have to agree.

   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.)  ;)
>
>