From: Darren K. <da...@pr...> - 2009-12-21 23:54:15
|
It looks like you're suggesting using both static (template) and dynamic (inheritance) polymorphism: void diff(..., const DiffConfig& config); template <> struct Diff<SpectrumList, DiffConfig> { ... } I haven't thought through all the details, but I would guess that the template parameter is unnecessary, and we could rely on inheritance, i.e. diff calls in msdata, etc. would call down to the cv::diffs, and DiffConfig& would be passed as BaseConfig&. Darren On Mon, Dec 21, 2009 at 3:35 PM, Matthew Chambers <mat...@va...> wrote: > Actually a bigger issue than cv/data is the diff paradigm. All these > types need diff methods that are callable from the child namespaces' > Diffs. The only way I can see to do this that won't result in a tangled > mess of namespaces and using statements is to move all the diff code > into a single namespace like pwiz::data::diff (in separate files). Then > we can have one Diff template and it will always expect the diff() > methods to be in the pwiz::data::diff namespace. The objects passed to > the diff() methods don't have to be in that namespace. Handling the > configs will have to be templated too I expect. For example, see my > codepad paste: > http://codepad.org/YxS288tJ > > Does that arrangement make sense? Or is there a better way I'm not > seeing? The configs make it pretty ugly. > > -Matt > > > Matthew Chambers wrote: >> How 'bout UserParam/ParamContainer/ParamGroup? It could be confusing to >> not move these if CVParam moves (especially since they're also all used >> by MSData/MzIdentML/TraData). But UserParam doesn't make sense in >> pwiz::cv. :P >> >> -Matt >> >> >> Darren Kessner wrote: >> >>> I think it's a good idea. I like pwiz::cv. >>> >>> >>> Darren >>> >>> >>> >>> On Mon, Dec 21, 2009 at 12:25 PM, Matthew Chambers >>> <mat...@va...> wrote: >>> >>> >>>> Hi all, >>>> >>>> I'd like to move CV/CVParam/UserParam into pwiz/data/common for pwiz 2.0 >>>> since they are now used by msdata, tradata, mziddata, and sooner or >>>> later proteome as well. I'm a bit stuck about what namespace to use >>>> though. We moved CVID to the pwiz namespace a few months ago and I'd now >>>> like to move it to a child namespace like pwiz::data or pwiz::cv. But I >>>> don't want to unilaterally pick between the first option or whether to >>>> use both of them (Index/MemoryIndex/BinaryIndexStream went in pwiz::data >>>> and wouldn't make sense in pwiz::cv). This is not just a cosmetic >>>> change, it means that using the non-msdata modules with CV support won't >>>> drag in the full msdata module. I will of course handle all the >>>> necessary downstream changes to make sure everything still builds. >>>> >>>> Thoughts? >>>> -Matt >>>> >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> proteowizard-developer mailing list >> pro...@li... >> https://lists.sourceforge.net/lists/listinfo/proteowizard-developer >> > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > proteowizard-developer mailing list > pro...@li... > https://lists.sourceforge.net/lists/listinfo/proteowizard-developer > |