Leo Sutic wrote:
>
> > From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
> >
> > Anyway, I'm changing my -1 to the removal of
> > lookup(role,hint) to a +0 not to interfere with A5.
>
> Replacing your -1 with mine.
>
> > As for Berin's proposal, I think that the use cases you
> > outlined, not all of them belong to Avalon.
>
> Container portability is good and all, but it forces the
> concept of what a component is to become much narrower.
I'll tell you the whole truth: the very first Avalon design didn't have
components at all.
Shoking my town :)
Yep, Avalon composed Blocks. Blocks were the software equivalent of lego
bricks. Where polymorphic objects.
Blocks had version, metadata dependencies, they were thread-safe, they
were big.
I remember a pretty heated discussion with Peter about the size of
blocks. That time I even managed to change his mind ;-)
Components were introduced later and were introduced mostly because the
block patterns could be used inside the blocks as well, but where
portability was not an issue anymore.
So, we had the big reusable/sharable pieces called Blocks and the small
pieces called Components.
In short, Components were classes++, classes that followed the Avalon
model. Since in java you want to the ability to instantiate a particular
class, the need for hints emerged for Components (never for blocks!).
Result: ComponentSelector.
At that point I left this community for personal reasons.
I come back a while after and:
1) blocks are deprecated
2) components are becoming blocks
3) direct component instantiation is considered harmful
Without even noticing, the pure-COP promoters are going backwards: we
were there already, you simply changed the name of 'block' to
'component'.
> In Cocoon, a component can be something very small,
> and in A5, a component will be something quite big.
Gosh, things would be easier if you didn't deprecate the concept of
'block' and wanted to use the same name for two different things.
block -> an avalon-lifecycle-aware polymorphic object, versionned,
fully reentrant, sharable, not directly referentiable
component -> an avalon-lifecycle-aware polymorphic object, directly
referentiable
It's evident why we wan't find agreement on how to lookup components:
lookup(role)
returns a Block, while
lookup(role, hint)
returns a Component.
Cocoon, being itself block-like, references components. This is why it
needs the ability to reference them directly.
Phoenix/Merlin, on the other hand, being block containers, don't like
hints because blocks are not directly referentiable (nor they should
be!)
*THIS* is, IMO, the biggest design mistake done during my absence: you
merged two different things into one, without understanding that they
were totally different and they only thing they shared was
avalon-lifecycle awareness.
> I'm not sure if I like that change. Much of what used
> to be "applications using the Avalon framework" are now
> so small that they would be individual components.
> Don't ignore the small people, please!
I agree. We should not.
> Don't let Avalon
> become something that is a heavyweight "for big jobs
> only" framework. I'm sure there's a need for being able
> to put small stuff into a container and have it pooled /
> managed. That was the beauty of A4.
> I'm sure we can find something that allows Avalon to scale
> from small to big stuff.
Hopefully the above will bring context.
> As for the argument of use and abuse of Avalon, if someone
> can take this framework, and produce a usable product with
> it, how can we call that "abuse"?
No, careful. Cocoon is block-like and required special treatment of
internal components. That pushed more and more pressure on the handling
on 'components' (using the terminology above, not the current avalon
one) that twisted the clean design of Avalon.
Removing the 'block' pillar forced too much pressure on the current
concept of Component, leading to 'abuse' of patterns and the creation of
inelegant solutions (like ComponentSelector, for example, which nobody
ever liked but it was approved for need)
> The way it is used in
> Cocoon may not be what we consider proper and beautiful,
> but it remains a fact that people have found Avalon to be
> very useful that way.
Yes, there is definately the need for two different kinds of polymorphic
composition: direct and indirect. Direct is for small things that are
not sharable nor interoperable, most of the time, application-specific,
indirect is for bigger things, sharable, interoperable and fully
reentrant.
> Coming and saying "abuse! That's not
> how we want you to use our framework" has quite a high
> piss-off factor, migration path or not.
Unless you clearly show why.
> > I call for a restate of the Avalon's project charter!
>
> OK, so what do you propose we change it to?
"restate" in my vocabulary means: 'state again'.
I did in my previous email :)
Hope this helps giving more context.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
