[TransWarp] Addition and Recipe Order? (was Re: Components Stable?)

[Phillip J. Eby]

At 06:53 PM 6/19/01 -0700, ender wrote:
>On Tuesday 19 June 2001 04:41, Phillip J. Eby wrote:
>>>At 10:31 AM 6/19/01 +0800, Dirksen Lau wrote:
>>>>  
>>>> I'm developing a zope product when I discover TransWarp. I'd like to see
>>>
>>>some
>>>
>>>> examples how to develop zope product with TransWarp. Is there any of that
>>>> in Zope's download page?
>>>>  
>>>
>>>Sorry, no.  TransWarp is in a very early stage of development right now -
>>> it's only been last week that I began use of it in a "real" project, and
>>> only for its component-building tools, not any of the advanced parts.
>
>is the components building stuff stable then?, i'd like to start using it in 
>a project, but have been unsure about stability while watching the cvs 
>checkins.
>

Depends on your definition of stable.  :)  I'd say this is alpha at the
moment.  The TW component work I've been doing is in a not-very-critical
reporting feature of a project, and that feature went into a beta phase
yesterday.

Probability of bugs in the TW.Components family of modules is fairly low in
general right now, and those things that have unit tests are pretty darn
stable.  The stuff that isn't covered by unit tests yet may be buggy or
subject to interface changes.  There's also one major potential interface
change that could take place: ordering of Recipes and adding specifications
together.

Ty has argued that the ordering of Recipe objects and of aspect addition is
backwards, because it doesn't match Python base class order.  My view is
that base class order is irrelevant, because component construction is
nothing like inheritance in how it works.  Adding together aspects or
templates is a process of overlaying things, so to me:

A + B

and 

Recipe(A,B)

mean "put B on top of A".  Ty's view is that if you want to put B on top of
A, you should say B + A or Recipe(B,A), the way Python base classes work.  

Thing is, TransWarp actually works with the sequence A,B to put B on top of
A, because builders *do* in fact build up on top of one another.  So if I
decide to use Python ordering, I'll have to internally *reverse* the
contents of recipes in order to use them.  This is probably very minor as a
performance issue, but it just seems "wrong" to me because it hides the
sequencing of component build operations - which is something you *may need
to know about* when composing complex specification objects whose behavior
depends on what you overlay them on.  Ty's counter-argument is that this is
a logical sequence, not a physical one, and that left-to-right or
right-to-left ordering is separate from the *meaning* of the sequence.  In
other words, Python base classes overlay in the opposite order, and this is
perfectly understandable.  :)

My counter-argument to that is that the Python base class order reflects
implementation of a *search path*, which is not *assembly order*, and that
we should *reinforce* the distinction between the two.  Python classes
simply *refer* to their bases and use them for attribute lookups.
TransWarp specifications are used to implement a component and then
discarded; there is no search order involved.  To me, using the same
ordering diminishes the vast difference between these behaviors - an
important distinction that developers need to be aware of.

Ty's counter to this is that similarity will make it easier for developers
to learn, and having the order "backwards" from Python will result in
errors because people will naturally want to put things in base class order
rather than addition order.

So...  at this point, we are obviously deadlocked on this issue - probably
the first time we've *ever* been deadlocked on a design decision.  At this
point, we'd like to hear from some Python developers *other* than ourselves
for an opinion.  We do need to make this decision final soon, however,
because it represents a *major* interface and documentation change if we
switch to base-class oriented ordering.

Comments from the list are invited and encouraged!