> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> > From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> >
> > > From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> > >
> > > > From: Leo Sutic [mailto:[EMAIL PROTECTED]]
> > > >
>
> Hmm. What we have here is a bad design. Should the
> container make up for your poor design? Can you really get
> away with only three instances in a pool with a web
> environment? Honestly, there is nothing in Cocoon that does
> what you are talking about.
Yes, it is bad design. It is more than that - it is horrible design.
But admit one thing: It was not difficult to see that it was
utterly atrocious!
I meant to use it to show a situation that may occur in a system. It
will
not be as clearly awful as the abomination I showed you, but *hidden*
in the code. I can show you more poor architecture:
public void tailRecursive (int i) {
if (i < 100) {
mycomp = lookup (...);
tailRecursive (i + 1);
}
}
Of course, the component should be passed in to the method. The point is
that you may have these patterns in your system on a much larger scale
*without knowing* it.
You will suddenly experience massive slowdowns and not know what is
happening. After a few hours or days of going through code you realize
that
a certain method is being called multiple times. And that method does a
lookup.
> You have something more than "I may want to implement this
> poor design some day" that we can discuss?
As I said above, I tried to show you a pattern by distilling it
to a very short example. Apparently I failed so badly that you
thought I really advocated writing of such code.
> Why not discourage bad design?
Why not? Well, it depends on how that discouragement is done.
If designing your component poorly leads to YourCodeSucksErrors being
thrown all over the place (with correct line number and file info) the
moment you start the server, then I'm all for it.
But if, when you do something that is completely correct within the
context of your component, but, in interaction with other parts of the
system that you may not know of, leads to sporadic and erratic behaviour
seemingly unrelated to your code - then that discouragement is not
helping anyone.
> Now, a way to philisophically enforce the "do" vs.
> "represent" concept is to call the components by a new name:
> services. A service is a type of component that "does"
> something or performs a service.
OK, got it.
I disagree, but that is for another time.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
