Hi, Thanks for the reply Nicklas. It makes a lot of sense to create abstract classes as you suggest. We'll investigate what things we'd like to have in an AbstractPluginExecuter class, but mainly I think is code having to do with data import/export and plugin permisssions. But I'm sure others will have different opinions about this.
/Adam On Aug 29, 2007, at 6:35 PM, Nicklas Nordborg wrote: > Adam Ameur wrote: >> Hi, >> >> I would like to extend some methods in the Base1PluginExecuter for >> another purpose. > > I think we need to be careful about this. The Base1PluginExecuter and > BioAssaySetExporter was designed and implemented to solve ONE specific > problem: Being able to run plug-ins developed for BASE 1 under BASE 2. > > I can understand why people want to use the two classes for other but > similar purposes since they contain a lot of useful code. Considering > the historical changes (which has been large) in those two classes I > don't think they are stable enough to make subclassing an appropriate > solution in this case. Making methods 'public' or 'protected' > instead of > 'private' also means a future commitment to not change the contract of > those methods (ie. method name, method parameters, return values, what > they are supposed to do, etc...). > > The developers of the Affymetrix-related plug-ins, RMAExpress and > Plier > (http://lev.thep.lu.se/trac/baseplugins/wiki/se.lu.thep.affymetrix), > faced almost the same problem. In this case, the RMAExpress plug-in > was > developed first. When development on the Plier plug-in started the > developers realized that a lot of code was very similar and moved much > code to an abstract base class: AbstractExternalBinaryPlugin > > I think a similar approach is a better solution also in the case of > the > Base1PluginExecuter and BioAssaySetExporter. That is, we should > introduce the abstract classes AbstractPluginExecuter and > AbstractBioAssaySetExporter. The hard part will be to decide what > should > go into the new abstract classes. The existing code will not take > us all > the way. I think we also need Vegard's and Adam's use cases to find a > common pattern that can be used when designing the abstract classes. > > Other opinions on this matter and offers to help with the > implementation > are welcome. > > /Nicklas > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a > browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > basedb-devel mailing list > basedb-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/basedb-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ basedb-devel mailing list basedb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/basedb-devel
