[TransWarp] Proposed peak.binding API change

[Ty Sarna]

> >I'm -1 on Provide/Require...  too much implication of dependancy
> >ordering, module dependancies, etc for me,
> 
> That's what it's *supposed* to imply!  :)

Yes, but misleadingly so.  The use here is quite different, so I think
drawing a close a parallel confuses more than it illuminates.

> >class, there should be a corresponding provide in another or something
> >like that.
> 
> And well you should wonder, because generally speaking, yes, there *should* 
> be a corresponding source for something you require.  Of course, you could 

I said that there should be a *corresponding Provide*, not just a
corresponding source.  You have glazed over the crux of the confusion
that this teminology creates, but I don't think most people will.  In
every other context I can think of where "require/provide" terminology
is used, there must be at least one Provide somewhere for each Require,
which is definately not the case here.

> strong a require/provide implication: Require, Supply, Use.  A component 
> "requires" things of its context, "supplies" things to itself, and may make 
> "use" of its components.  Any of the things that are "required", 

The distinctions here seem really unclear to me...  It isn't normally
necessary to supply things to onesself.  And if I did want to supply it
to myself, wouldn't I also want to use it? And how do I know when I can
use something, and when I must supply it to myself to use it? 

> "supplied", or "used" may also be "offered" to the component's subcomponents.

"supplied" may also be confusing while trying to explain things.  If
there is foo = binding.Supply(...), and you describe that as "supplied",
that sounds like something supplied from elsewhere, not something I'm
supplying.

> Possible terminology:
> 
> Require    Supply     Use
> Obtain     Make       Reference

Better, but Obtain vs Reference is still a little unclear here. If you
asked me what the difference between obtaining something and referencing
it might be, I'd think reference was a pointer operation vs Obtain being
perhaps making a copy, or "taking away" from somewhere else, or
something (since any other way of obtaining something in python just
gets you a python reference anyway!). Also, there is the peak.naming
meaning of Reference to contend with.

> Acquire    Build      Refer

I still don't get it :-)

> Take       Produce    Attach

I'm going to attach it without taking it? or take it away from something
else but not attach it?

> All in all, I think most of the benefit of a three-way split is for the 
> code's reader. 

I dunno, I think it confuses me quite a bit more than the 2-way names,
even :-)

It reminds me a bit of that document with "the difference between Orders
and Purchases is like the difference between a Purchase Order for a
product and the actual product."

It leaves me with a feeling of "well, after reading that a couple times,
I guess understand the difference, but the way it was worded I won't
be sure I'm remembering it right, because it all sounds too similar and
it sounds like I want both." Making me choose between Obtaining and
Using, or whatever, is like making me choose between Ordering and
Purchasing. :-)

Anyway, if you're wanting something to appeal more/be easier to explain
to a wider audience (which I guess means more "3,4"-ish programmers), is
moving from the current "here's what they do" names to names based on
more abstract conceptual groupings of things the right way?

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.