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

[John D.Heintz]

> 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

I find this description very motivating.  Given proper documentation I can 
live with the current component construction semantics and mechanics even 
though they differ from a Python expectation.

John

On Wednesday 20 June 2001 06:43, Phillip J. Eby wrote:
> 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!
>
>
> _______________________________________________
> TransWarp mailing list
> TransWarp at eby-sarna.com
> http://www.eby-sarna.com/mailman/listinfo/transwarp

-- 
. . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | jheintz at isogen.com

w w w . d a t a c h a n n e l . c o m