On Mon, 11 Feb 2002 21:01, Paul Hammant wrote: > 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?
You can demote parameters to demothds and add constants but little else. ie Get it right first time or not all :) 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. Not sure what you are going on about here. I mean backwards incompatible because if you made either change you would subsequently break oodles of code including, ExcaliburComponentManager, Cocoon, Phoenix, Myrmidon and anything else that defines their own CM or relies on return type. So are you saying this is not a problem or what? > >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? No - it will break Phoenix and any other code that defines a custom CM ;) -- Cheers, Pete *----------------------------------------------* | The best defense against logic is ignorance. | *----------------------------------------------* -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
