Berin Loritsch wrote:
>>From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
>>
>>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"?
>
>
> No. The XML or SAX stream is the information.
Then a Socket is not information.
The stream is.
A socket is an information endpoint, as Generators are with XML.
> They represent different stages of how to create or manipulate
> that information. They also provide a nice abstraction so that
> you can easily understand how they relate to each other.
I agree, only that I don't understand why a Socket is information.
A Socket is an abstraction, you don't have sockets in your cabinet, do
you? ;-P
>>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 :-?
>
>
> I am in the process of refactoring software that was clearly not
> designed. It mixes OO and procedural concepts providing an
> incomprehensible mush.
>
> I *really* hate bad/no design.
Yeah, I feel your pain, brother.
>>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.
>
> :)
>
> It would satisfy the technical requirements for being a component.
Ok, then it is.
A bad component? Maybe.
But a component nevertheless.
> But what does it do?
>
> Think of your system as a play. You have actors that perform.
> They have a set script, contracts so to speak. Whether it is
> Mel Gibson or Mark Hammel (I prefer Mel) playing Hamlet, the
> performance goes through the same mechanical aspects of the
> script. The performance is quite different, but the end effect
> is the same.
>
> Remember that actors interact with their surroundings. Unless
> you are watching mime or some avante guard neo classical crap
> they interact with props. Props can be just as important as
> the actor, esp. in murder mysteries.
>
> Try to break down your components like you would have actors
> tell a story. The story in this case is what your system does.
> If you want your system to be like a Saturday morning cartoon,
> then having animated props (like a talking blanket) is appropriate.
> However, don't complain to me if your Saturday morning cartoon
> doesn't scale up to the big screen.
:-))
> That is the general rule of thumb, and why we refer to components
> by their "Role".
Every system can be analysed at different levels, and this "play"
metaphore yields different results with different levels.
This is what makes it so difficult IMHO.
It seems that Avalon is geared towards coarse grained components, and as
time goes by I'm more and more confident of this.
That's why I didn't make Tweety itself a Component in the first place BTW.
--
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]>
