Berin Loritsch wrote:
>>Your definition of Component is too flimsy.
>>Give me a set of rules, and let's stick to that.
>
>
> I could write a book on the subject (oh, yeah...).
>
> Let's just say that I am not going to put 20+
> pages of spoilers on the list. You'll just have to
> be patient. What I gave you is what the component
> community can agree upon.
Which is nothing ;-)
Seriously, what about Cocoon using Serializers, Transformers,
etc as Components.
Aren't they "information"?
Any rule that is not enforcible or easily explainable is a bad rule.
What's the rule for a Component?
1) Separate interface from implementation
Easy to do, even with Sockets ie Socket implements Endpoint
2) No argument public constructor
Easy here too
3) Distributed in binary form (aka jar file)
Plain easy.
In Avalon, I would add: "is treated following the lifecycle rules"
You wrote:
> Again, you have to have the proper abstraction.
> In this case,
> the Socket itself is the *wrong* abstraction.
> The container
> should not make up for your poor design habits.
I this Berin or Peter Donald :-?
Ok, se let's call it MyAbstractConnectionEndpoint.
And have Socket, MYSocket, WoolThreadEndpoint implement it.
Would it be a Component, given the above premises?
I think there is something plain confusing in all this.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
