avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@d-haven.org>
Subject Re: More on contract strength (was Re: Unifying Vision)
Date Wed, 10 Mar 2004 16:59:59 GMT
Niclas Hedhman wrote:

> On Thursday 11 March 2004 00:09, Niclas Hedhman wrote:
>>On Wednesday 10 March 2004 22:37, Berin Loritsch wrote:
>>>I am all in favor of *controlled* contracts.  They provide a reasonable
>>>foundation to build with, and yet still alow for some amount of
>>>flexibility. No-one on this list has ever advocated complete hippy
>>>free-bird approach to development.  I don't think that has ever been a
>>Are you suggesting that the 4 (out of 4 possible) different lookup
>>semantics of ServiceManager is a desirable result of 'flexibility'?  If so,
>>we are on different trains, and will end up at different destinations...
> Since I believe you will answer "No, that was not intended", you may answer 
> the question "So, how did we (even if I was not around, I still consider it a 
> community thingy) end up with it?"  You were around and must have observed it 
> happening... And I can for no reason have a clue how it was allowed...

Easy answer is that at that time there was no community, much less consensus
on it.  Before, it was wide open and anything could map to anything, with no
control.  There were big conversations to help make it more reasonable in
respects to looking up services.  At that time, the concensus is what was
written in the DWA paper.  Based on the tools available at that time, the
choice of looking up a service based on the interface name was a natural and
simple solution.

The problem came in as we evolved the container code based on these assumptions.
ECM made it a bit easier to use the guidelines by adding some semantics to them
that the ECM would handle automatically (in hindsight, it was too much magic).
Meanwhile, as time went on, Phoenix experimented with attributes tagged in the
source code.  Since Phoenix was able to provide assurances without the need for
selectors or mapping interface names to lookup values it evolved along those
lines.  Now Merlin actively discourages mapping lookup values to interface
FQCNs.  Fortress came on the scene to help with the transition from needing
interface names for lookup values and selectors, but still supported it due to
the need for using existing components.

That is the nutshell view of how we got where we are.  Fortress sits between
ECM and Phoenix, and Merlin is somewhere past Phoenix.

In a sense, we went from a stronger contract to a weaker one on the key names.
Was this bad?  No, because the overall contracts were made stronger due to the
meta information.

A perfect example of what I view to be a bad contract is the Meta package in
the avalon module.  It is unnecessarily strict in that any user of the package
must supply any of the myriad of undocumented contracts that Merlin has with it.
The contract is with the XML data format, the serialized format, etc.  The
information is not stored with the class itself.  A better contract is one where
we supply the code for the attributes, but use something less restrictive in
how to set up and use like Commons Attributes.  You can still provide the
Attribute classes to provide strong contracts, but you are not locked into
only using the meta information defined by the meta package.  Since you are into
tools, there are some meta data that would help tools out but not really be
useful at runtime.  Do you want to really go to the mat with Stephen to add
that meta data definition to the Meta package?

You can still provide strong typing and strong contracts without forcing the
hand on a non-intuitive library.  Are we getting closer to the same page here?

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message