avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Federico Barbieri <scoo...@betaversion.org>
Subject Re: [proposal] Primitive and composite patterns
Date Tue, 27 Feb 2001 06:01:15 GMT
Peter Donald wrote:
> At 05:23  26/2/01 -0800, Federico Barbieri wrote:
> >It's a general rule it's better to have primitive than composite
> >packages... because they don't have dependencies and they enforce SOC. I
> >may like the avalon.pool interfaces but I don't want to inherit all
> >component contracts. This make perfect sense.
> The problem is that if you want to place anything in a CM then it needs to
> implement Component - which is why some people I talked to said either
> *everything* should implement component or *nothing* should implement
> component and the CM should deal with objects. Thats the main reason why
> Pool etal extend Component.

not sure... being a Recyclabe doesn't imply being a component too... so
I can have a pool being a Component and working with the CM but I can
have a pool NOT implementing component as stand alone. 

The reason I want to clear this is simple... container is a desing
pattern that is exteremly useful in many situation, including phoenix
and its blocks, a servlet container and its servlet etc. If we can't
decouple container from component then a SE can't benefit of the
patterns since servlet ARE NOT components. This whould be a pity... 

> >So my first question is: container is right now a composite since uses
> >component. Is it right? Can we have a container package unaware of
> >components? If so it's critical not to mix contracts and clean it.
> See above. Remember that container (which I still thinkg should be camelot)
> is not just a container package but has other things like deployment (and
> will have installing when I differentiate between install/deploy). If we
> want to call it conatiner it should be further differentaited but I think
> it will lead to confusion (hence the abstract name that has no semantic
> connotations).

Then does it make sense to have a clean container package component
unaware and a higher camelot package component aware? The container can
be small but it's reusable by all container, camelot is for component
oriented containers (phoenix etc.).

> Cheers,
> Pete


View raw message