Leo Simons wrote:
>>>>Leo, I still think that having made the main class a Component itself
>>>>with the lifecycle methods is confusing for early users, as well as the
>>>>fact that main() makes it call them on itself :-S
>>>
>>>
>>>hmm. having main() instantiate a copy of itself is, I think, quite
>>>common behaviour.
>>
>>Which I don't like much.
>
>
> agreed. main() in java is basically your entry point into the
> bootstrapping process. It'd been better if there'd be an interface
> java.lang.Mainable with a main() method, which you'd always use.
>
> you should in general not look at main() as being part of any object,
> but just some place to put the procedural code that starts your
> application. Like main() in C.
Yup :-)
Mainable... hehehe it's kind of strange, but intriguing ;-)
>> > The alternative is to have another class, called Main,
>>
>>>that instantiates Tweety. Wonder what is clearer.
>>
>>IMO the second.
>
>
> will do.
>
>
>>>>I would just revert to the old behaviour which is more simple, and
>>>>thought you kinda agreed on this...
>>>>
>>>>What do you think?
>>>
>>>Like I said earlier (I think), not making Tweety a component would be an
>>>example of bad design. If you just use tweety, you just type 'ant run'
>>>and never deal with anything of its internals, so the *exposed*
>>>behaviour is exactly the same. If you want to look at the source to
>>>Tweety to learn what it does, I think it is very important that the
>>>source is well-written according to our own standards.
>>
>>Less is more.
>>If we want to explain how Container-Component works, we should make a
>>Container and Components, not A Container that is a Component and a
>>Component.
>>
>>Making everything a Component has lead to the misuse we have in Cocoon,
>>and this only encourages it.
>
> hmm. I think it is perfectly smart to make a Container into a Component,
> as it allows that Container to be used in other Containers. This is
> completely separate from the cocoon case.
But this is for educational purposes.
Making container hierarchies is an additional thing, I wanted to keep
Tweety really really really barebone, ie cannot be less than that.
>>>And the less pronounced motive is that I'm sure people will be misusing
>>>Tweety, for example putting it inside phoenix or somethin'. While I
>>>'officially' disprove, I can see why =)
>>
>>Hey, this is why I *don't* want Tweety itself to be a Component.
>>If it is, as now, users *will* ignore main and use it as a Component.
>>
>>Sorry, but I don't understand Leo, it seems confusing to me what you say.
>>
>>I want Tweety *not* to have lifecycle methods.
>>Lifecycle methods help in IoC, but if it calls them on himself it's a
>>very bad programming example.
>
>
> but it doesn't call them on itself.
;-) On a method defined in its class.
> They're called from main(), which
> isn't really part of the class. Will change though.
Ok, this will make it much better.
>>There is no inversion, no clear Container-Component separation.
>
> if we had interfaces:
>
> interface Component { /* ... */ }
> interface Container { /* ... */ }
>
> I think it is perfectly cool to have
>
> class ContainerImpl implements Component, Container { /* ... */ }
>
> or even do:
>
> interface Container extends Component {} /* not handy in the avalon
> case, but okay conceptually */
>
> IOW, the relationship in OOP terms is: "A container is-a component".
>
> This is a valuable lesson to teach; it makes reuse possible. It is what
> the other avalon containers do, innit?
Hmmm... yes, good point+example... it seems that both your vision and
mine have things to teach.
I think you are right in wanting to have Main-Container-Components.
What I don't like much is the fact that the Main in this case works as a
Container itself, since the Container is seen as a Component from Main.
...
Maybe we could just keep two approaches:
1 Main-Component (shows lifecycle calling)
2 Main-Container-Component (delegates lifecycle calling to a container)
This way a tutorial can first show 1 to explain lifecycle, then show 2
to introduce the Container abstraction.
Maybe a ComponentRunner (1) (runs lifecycle) and a ContainerRunner (2)
(runs tweety which is the simple container).
--
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]>
