Vadim Gritsenko wrote:
Berin Loritsch wrote:
Vadim Gritsenko wrote:
Berin,
Please see example sent in response to Ken's question:
Generator g;
Component c = g;
This *will* fail to compile.
However, when would this ever happen?
When, say, you happen to collect components in an array. Or see below.
How about an array of Objects? It works just as well. Although if it
is an array that will be used at runtime, a fully typed aray is better.
Who ever goes from an interface with methods to one without methods?
Avalon does ;-)
Or any avalon-like code, like CocoonComponentManager (which means
chances are there is MyCompanyComponentManager somewhere out there).
Well in Avalon they go to Object, not Component.
This only seems to be an accademic issue, and not a real world code
example.
Berin, that was you who taught us to work hard to keep backward
compatibility. It should be you who should argue on this point instead
of me! But if you want to go down the road of "academic" and "practical"
backward compatibility, then I rest my case.
And I am trying to point out that we have a backwards compatible
approach that allows for a smooth migration from not needing the
Component interface.
All expected uses of the Component interface have been accounted
for.
Yes we should try to keep backwards compatibility. You can go crazy
trying to think of every bastardization of the accepted use and corner
yourself into ineffectualness.
IOW, what does it buy you to perform the bad code snippet above?
For all practical and real requirements, it is safe to remove the
Component interface from the Generator interface, et. al.
Upgrading to Fortress or the CVS version of ECM, and then removing
the Component interface from the core interfaces should give you
the piece of mind that everything should compile and run.
Try it as an experiment.
I'm planning to. Really. When fortress is "ready" - or, better one -
when beta release is due?
But do not complain when it breaks compilation of your favorite client's
code ;-)
It *shouldn't*.
I have not had any problems to date.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
