> Yes, you are right. But this is exactly the point: if we have one
> container (or a chain of containers extending one another), then
> we force the community to agree on how to define components.
And if there are differing ways to do something, then you force the
community to come up with a pluggable interface for abstracting the higher
level semantic, which focuses more attention on that area.
> 1) Avalon agrees on having one modular container or several containers
> that extend one another
Yes, although I think that the term "extend" is overloaded, and should be
used with caution.
> 1) there is *one* framework and *one* definition of components
> 2) components interoperate between container implementations
> 3) behavior is inherited between extending containers so that
> maintenance and back compatibility is easier to control
Agreed to all, with the caveat that I believe you'll find that some areas
will not inherit implementation, but will implement an interface
differently. Over time I hope that these areas will diminish, but being
pragmatic, I recognize that there will be different needs, which will be
addressed by different implementations. But if 80% of code, and 90% of the
internal interfaces, and 100% of the Framework interfaces are shared; and
100% of the differences are understood, agreed and justified; then that
would be rather different than the current situation.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
