Paul:
Aside from the backwards incompatible question there are some nasties in taking approach of the addition of a "resolve" method. If you try working up a modified version of ComponentManager (which I did and threw away), you end up having to add "getObjectMap" and "hasObject" because "getComponentMap" only returns the map for Component instances and "hasComponent" returns TRUE only if the object is a Component. Secondly, you need to make a decision concerning (a) maintaining one or two HashMaps. If you maintain one HashMap containing objects you then need to put in [instanceof Component] on "hasComponent" and "lookup" and you need filter out non-Component references when returning a Map from getComponentMap. If you choose to use two HashMaps you then have to decide if your going to duplicate component reference in you object map or manage the creation of a combined component/object map from the getObjectMap method. It's not brain surgery - just brain damage - you end up with multiple methods doing basically the same thing and turning the implementation into something confusing. Steve. > -----Original Message----- > From: Paul Hammant [mailto:[EMAIL PROTECTED]] > Sent: Monday, 11 February, 2002 12:24 > To: Avalon Developers List > Subject: Re: ComponentManager interface > > > Peter > > >>>>(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? > > > Yes, it is not a problem. The (2) proposition is about an *additional* > method called "lookup2" or "resolve". > > > > >>>o +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 ;) > > > Phoenix merely has to implement "resolve" in addition to the "lookup" > method. Not brain surgery. It is a compile time only issue. > > I could make all the compatability changes myself. For example if > Cocoon had it's own impl of CompMgr, I could implement the new method. > Get it to throw a RuntimeException knowing there is no part of the > current Cocoon using it. Thus we have a version of Cocoon that will > compile against the pre and post versions of framework. Which one the > Cocoon team book in is up to them. I would change no other > functionality. No up or down casting anywhere. > > Regards, > > - Paul > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
