Peter,
>>Our three choices again, with Gerhard's too.
>>
>>(1) Change Component to Object for lookup method
>>
>
>-1 - backwards incompatible
>
>>(2) Create a new method in the same ComponentManager interface
>>
>> variations : "lookup2", "resolve"
>>
>
>-1 - backwards incompatible
>
So interfaces, once defined are immutable? Hmmm, I think you made a
mistake here. Adding a method was "relaxed" as an incompatability when
JDK migrated from 1.1 to 1.2. Before then. any diffrence in any method
as illustrated by some checksum/hash/serialID was enough to make the JVM
barf. After that it would consider methods on a case by case basis
before deciding to barf. Compilation is different of course, but I will
not accept the two word phrase "backwards incompatible" for this.
Keep your objection Peter by all means, but do not cite backwards
compatible as the reason....
>>(3) Clone a set of interfaces & exceptions into a new package, either
>>with the same names, or not.
>>
>>(4) Create a new interface in the existing package
>>
>> e.g. GenericComponentManager
>>
>
>either of those are backwards compatible so fine.
>
>>PD> If Sun jumped off a cliff would you do it too ?
>>
>>No, but I think that a "2" suffix is not so objectionable to get around a
>>return type issue.
>>
>
>perhaps. I wont veto it but I really dislike it. Consider LogEnabled vs
>Loggable2 - which do you think is easier to understand/read. :)
>
Not quite the same think. LogEnabled / Loggable is not Avalon's raisen
detre. Component Assemply, Component orientated Programming is.
Beside, you know how much trouble we got in over logging. We have a
framework that is multiple years old. Did some refactoring/asbtarctions
six months ago, and lo and behold the commons team dive in with Apache's
third logging framework. It ends up looking like ours with the same
multiple implementations. Part of that <conjecture/>could be because of
the name of the beast - LogEnabled rather than first choices - Logger &
Loggable.
Let me raise another example: JDBC. Sun changed massively the methods
on the latest interfaces for this. It is not possible even to cross
compile them. Luckily for us and AvalonDB Ant has an <exclude/>
directive and with Java extends I can have one codebase for both
versions. JDBC is in far wider use than Avalon. I guess it is a jump
of cliff/bridge issue again, but Sun did not baulk at the prospect.
>So +1 to doing something backwards compatible in framework4.x
>
Given that (2) is backwards compatible in so far as code compiled for
the current ComponentManager would continue to work for a future version
with *extra* methods, is (2) back in the running?
>If this aint accepted then we can prototype framework5 relatively fast and
>even keep it compatible with framework4.x by putting it in a new package. ie
>we could go back to
>
while (unhappy) {
newPackage = package.clone();
}
>org.apache.framework
>
- Paul
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
