On 06.11.2016 00:02, Michaël Michaud wrote: > Hi Ede, hey Mike,
> A question about plugin design. > > In 2012, you added both > - an EnableCheck interface implemented by AbstractPlugIn > - an implementation of this interface in AbstractPlugIn which retrieve > older createEnableCheck method by reflexion sounds familiar > I'd like to add a comment in the code. Am I right to say > - the prefered way to add EnableCheck in a new PlugIn is to implement > getEnableCheck() > - implementation in AbstractPlugIn is just used to make legacy plugins > compatible with > new code using the new EnableCheck interface. pretty much, although i wouldn't say preferred, but new , as the way Icons or Checks were retrieved before was not standardized as such. > I ask because I realize that I always start from an existing plugin and > often use the old > createEnableCheck method (or even static createEnableCheck). i'd say that new Plugins should implement the proper interfaces Iconified, EnableChecked. >I think I'm > wrong and I > want to replace it by the getEnableCheck every tiem I review a plugin > but I want to have > your feedback first, old Plugins work fine because there is the legacy compatibility code you mentioned. so while i respect your cleanup initiative, i personally do not like to touch working code w/o fixing a bug or enhancing functionality. there is little to nothing to be gained, while risking to introduce bugs that weren't there before. happy sunday ..ede ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
