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

[ender]

On Wednesday 20 June 2001 04:43, Phillip J. Eby wrote:
>>At 06:53 PM 6/19/01 -0700, ender wrote:
>>>
>>>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.

most of what i'm interested is in at the moment are the Components and 
probably the other stuff that lives in the top level of TW.

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

my thoughts echo richards'.

i do find the current system to be intuitive, although i also find python's 
inheritance order to be unintuitive (perhaps even worthy of a pep, although 
legacy breakage would be horrendous).

from the AOP docs in TW, my simplisitic view of aspects was that of a 
namespace stack that gets merged at weave time. 

while i do find ty's concern to be persuasive, my own inclination is towards 
addition order as this seems more appropiate for the generation of an ordered 
sequence.

considering even simple  cases like

aspect A + aspect B 

do some stuff

aspect (A+B) + aspect C

it would def. seem backwards to me to get

aspect C + B + A 

 As long this is clearly documented, i think this should be acceptable to 
other programmers.

if your deadlock persists you might consider asking some of the members of 
python-dev about it. 

cheers

kapil