[PEAK] Re: Binding fever

John Landahl john at landahl.org
Mon Nov 3 15:16:22 EST 2003


Oops, that last message got away from me somehow before I was finished.

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

> At 09:49 AM 11/3/03 -0800, John Landahl wrote:
>> 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.

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

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

All the more reason we need things like definitions for all of the above 
terminology, and then some.  :)  Or for some of them which are common 
parlance, like factory functions or interfaces, perhaps more of an 
explanation of how they work in the context of binding.

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

Yes, I'm seeing how binding truly makes all of this possible.  Because 
PEAK allows you to bind right down at the object attribute level, rather 
than, say, at a more distant place like in deployment containers, it 
really brings things home, so to speak.  Programmer's aren't used to 
having that much flexibility at their fingertips because nearly every 
language up to now has forced you to do pass things around manually, but 
with PEAK you get this incredible flexibility right at the language level, 
or what effectively seems to be the language level from the programmer's 
point of view.

> 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 have to heartily agree with that sentiment!  After "getting" binding, 
I'm now switching as much as possible over to using protocol-based 
acquisition.  I'm really amazed at how much flexibility this provides.  
The possibilities seem limitless.

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

Ah, well, no one said anything about either wealth or fame.  My motivation 
is elucidation.  Sharing the knowledge, advancing the art.



More information about the PEAK mailing list