avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter M. Goldstein" <peter_m_goldst...@yahoo.com>
Subject RE: Framework and Contracts (was RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization ) )
Date Wed, 20 Nov 2002 21:11:04 GMT

Berin,

> > The "interfaces define everything" mentality is something that some
> > consumers of Avalon (myself included) find troubling.  Avalon
> > Framework
> > needs to (and in quite a few cases does) include conceptual
> > documentation that goes beyond the interfaces.
> 
> Does the "Developing with Avalon" documentation fall short in this
> respect?

It's a really good start.  It was very helpful to me personally when I
first got into Avalon.  But some niggling details still need to be
worked out and added to the framework and then added to the docs.  I'd
also like to see contracts defined more formally, rather than in what is
an essentially teaching-focused document.

> > Interfaces do not define anything save interfaces.  It's the
contracts
> > behind those interfaces that matter.  Without the contracts, the
> > interfaces are meaningless.
> 
> The interfaces are the points of contract that can be represented in
> code.  So it is *part* of the contract, but not the full contract.
> Your point on contracts is well taken, and I have put forth much
> effort to make the contracts explicit.

Yep.  I wasn't implying that there hasn't been any focus on contracts.
I just wanted to draw the current discussion back to the fundamentals
and ensure that everyone understood the crucial point (interface <<
contract).

> > Consider an Avalon Framework with all the lifecycle interfaces, but
no
> > lifecycle definition.  It would be useless - containers would
> > be able to
> > implement lifecycle methods in any order they desired.  You couldn't
> > write a container-independent application using such an Avalon
> > Framework.  It is the lifecycle contract that is fundamental.
> 
> That is the way that Avalon *used* to be.  The only contract was that
> initialize() was the last method called.  I took the time to work
> with Fede to define the contracts we have now.

I didn't know that.  :)  I'm much happier with how things are today.
 
> > This is only one Avalon Framework issue among a number that need to
be
> > discussed, clarified, and resolved.  Clarification of these
> > issues will
> > make it easier, not harder, to develop new containers.
> 
> Right.  Keep in mind the chicken and the egg issue.  How do we know
what
> needs to be commonly implemented unless we have multiple containers
> to work with.

Agreed.  This is an iterative process.  Right now we have a few
containers.  We can focus on these containers and talk about their
commonalities and divergences.  Other containers can also be considered.
The developers can turn their attention to these issues and start a
productive discussion.
 
> > The only way to get a truly multi-container world is precisely to be
> > crystal clear about what the Avalon Framework does and does not
> > guarantee.  I very much support multiple containers - and the
> > ability of
> > Avalon Framework consumers to write functional,
container-independent
> > applications.
> 
> Exactly.  What I proposed in another thread is the creation of
> a Container test suite that will work a container to determine if
> it meets the minimum requirements for Avalon container compliance.
> Again, remember the chicken and the egg issue.  Now that we have
> three robust containers, we can shore up the weaknesses in the
> contracts.

Yep, sounds like a good plan.

--Peter
 




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


Mime
View raw message