[equinox-dev] Re: Questions Regarding Changing Interfaces

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Overall, I suggest you deprecate old API for now.  This minimizes breakage (maximizing function) and expresses your intent.

re: get/setEnabled.  Its been a while since I looked at these.  I suspect that the API should just have isResolved(), isEnabled, isConfigured,...  Disabling, deconfiguring a plugin should be an operation on the PlatformConfiguration or some such.

re isDeactivated().  What is the intention here?  That is, what error state are you thinking of?  I could imagine wanting to know if a currently !isActivated() plugin has ever been isActivated().  Perhaps hasBeenActivated() or wasActivated()?  Those in combination with isActivated() should cover all states.

Jeff

Keith Kimball@IRIS 05/12/2003 11:38 AM

To:        Jeff McAffer/Ottawa/IBM@IBMCA         cc:                 Subject:        Questions Regarding Changing Interfaces

Jeff,

How much flexibility do we have at refactoring interfaces? The two places I would like to change names are:

• org.eclipse.core.runtime.model.PluginDescriptionModel.
  I would like to change the {get,set}Enabled to {get,set}Resolved to match Pascal's state diagram. The problem with this is that an internal PDE routine references it. I'm hoping to change the name prior to checkin but ...
  

• org.eclipse.core.internal.plugin.PluginDescriptor. I would like to change isPluginDeactivated to isPluginDeactivatedDueToError. This is not used outside of the runtime and I suspect this is ok.
  
  Keith