Sylvain Wallez wrote:
But I think it can even get easier:
1. Let's just assume that every component is ThreadSafe - unless
otherwise stated - no need to declare the interface anymore. I think
apart from the interpreter most components are threadsafe or poolable
anyway.
This is a huge change compared to the current behaviour, where no
interface means not threadsafe and not reusable. IMO, this change can
only happen if we completely move away from Avalon.
This is not the "safe" assumption, and can cause unexpected side-effects
in user's code. This is not a 2.x change.
2. Let's remove support for pooled components - yes, seriously. Fiddling
with the pool sizes is really annoying. We have a working factory
approach for sitemap components, so why not simply use it overall? And
rewriting the remaining pooled components shouldn't be that hard. (I now
that we are proxying pooled components to simplify the lookup, but you
still have to configure pool sizes).
+1 for generalizing the factory pattern. Cocoon spends way too much
time in checking Avalon's lifecycle interfaces and parsing
configuration objects.
Well, a better pool like the MPool package at D-Haven will help. MPool
is the managed pool that will shrink pool sizes at a slower rate,
removing the need to think about pool sizes in general (i.e. no
deferring back to factory method).
The big thing about Avalon based components is the startup time due to
the configuration element parsing, etc.
Now, I will say that getting rid of component pooling will require a
major overhaul of the Cocoon internals.
My final idea is to use even more magic (but it might be too much
magic?):
class MyComponent implements SOMETHING {
protected final ClassA component_A;
protected final ClassB component_B;
}
When the component is instantiated all instance variables prefixed with
"component_" are setup using some injection mechanism - or perhaps using
annotations?
Hmm...
- how do you unit test Cocoon without the container? By subclassing to
access the protected fields?
- we can't strongly enforce the contract of subclasses by making some
fields private.
- the naming convention weakens the strong typing of Java. What if you
write "conponent_A"? Chasing the NPE won't be easy...
Danger Will Robinson!
In addition to the reasons listed by Sylvain, you are deviating far into
left field from what the average Java developer is used to.
Now, in the end I really want to write less code :)
Use Ruby :-P
Seriously, I agree that writing less code is good, but not at the
price of too black magic implying weaker contracts.
Agreed. To achieve the goal of less code would require major overhauls
of the entire system.
- Re: [RT] Simplifying component handling Berin Loritsch
-
