> >>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.
> > 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.
> > 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. They're called from main(), which
isn't really part of the class. Will change though.
> 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?
cheers,
- Leo
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
