[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