[TransWarp] Proposed peak.binding API change

Phillip J. Eby pje at telecommunity.com
Wed Sep 3 19:33:02 EDT 2003


At 05:08 PM 9/3/03 -0400, Ty Sarna wrote:
>[snip lots of analysis]
>
>I think I'd much rather explain "if you want to do this, use this
>binding, if you want to do that, use the binding that does that" that
>suffer all the dirty looks I'd get from Lynn if I was trying to explain
>how to Obtain something without Referencing it, or vice versa.  :-)
>
>And Attr may be redundant, but at least it comfortingly confirms
>something I know, instead of making me wonder how words are being used
>in a particular context.

After thinking about it some more, following our in-person discussion of 
the above, I'm thinking of taking Jean Jordaan's suggestion of 'Make()' 
instead of Provide.  So you can either 'Require()' something from outside a 
component, or 'Make()' it yourself.  The name also implies the "make" tool, 
which, like this binding:

    1. produces a value based on a rule, possibly using other inputs
    2. stores that value so it doesn't have to be rebuilt (i.e., it invokes 
the recipe just once)
    3. doesn't have to be told what order to build things in

The downside, of course, is that "make" rebuilds a part when its 
dependencies have changed, and 'binding.Make()' does not.  One must view a 
'binding.Component' as representing the output of a single "make" run for 
this analogy to be truly accurate.  But, that's an issue that has to be 
addressed in the documentation anyway.

Last, but not least, "make" is one of only two words in my last post that 
you didn't object to.  :)  ("Produce" was the other.)




More information about the PEAK mailing list