Hi Ede, Thanks for your answer.
I know your position about cleaning and upgrading the code. I think there is no absolute rule in this domain. We can probably live for ever with old pieces of code named "workAroundForJava14" or on the contrary refactor the code at every turn. I think I reasonably fit in between ;-) Not only OpenJUMP is quite old and I see many benefits adopting java language features like generics, but I think there are much duplicate code which is not only ugly from a design perspective, but also disturbing for people who want to understand the code base. Michaël Le 06/11/2016 à 12:32, edgar.sol...@web.de a écrit : > 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 ------------------------------------------------------------------------------ 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
