From: Robert B. <rob...@pr...> - 2011-01-21 18:34:17
|
Hi Matt, So, in response: 1. Working directly from the xsd, there are elements that are extensions to IdentifiableType that have unbounded cvParam sequences in them, but no explicit structure like you propose. So, you see, it was simply the truest to design path available before I was familiar with both schema and library. I'm fine with either route, but lean heavily toward the latter choice as well. I'm assuming IdentifiableParamContainer would be a multiple inheritance IndentifiableType/ParamContainer. 2. Fine with me. Empty will have to be CVID_Unknown which gets printed as an error "??" anyway. The use of ParamContainer was a result of a discussion with Darren. I can't remember the meat of it, but IIRC, it was recommended for ease of coding and resilience of the code. Since mziddata is supposed to be a library used by the community, I'm very happy to adapt it to the community's preferences. For the record, some non-structural things that have bugged me since about the moment I typed them in are 3. the name mziddata, which I now think mzid would be better; and 4. the name IdentifiableType, which should simply be Identifiable. I haven't had the chance to change either due to time constraints, but if there's going to be any major changes I'd like to try and add those two in. -RB On Mon, Jan 17, 2011 at 8:12 AM, Matthew Chambers <mat...@gm...> wrote: > Before we get into the ResultList design, there are some easier changes I'm considering. > > 1. Lots of the types need both to inherit from both IdentifiableType and ParamContainer. In these > cases you inherited only from IdentifiableType and put ParamContainer in as a member like > "paramGroup". Is there a good reason not to use either multiple inheritance or a hierarchy like: > IdentifiableType -> IdentifiableParamContainer (and then inherit from whichever one is appropriate). > The latter approach is probably simpler. > > 2. There are some cases in the schema where there is an element meant to hold just a single CV > param. In most cases, these are represented as ParamContainers in mziddata. Examples: > ContactRole::role > SearchDatabase::fileFormat > SpectrumIdentificationProtocol::searchType > SpectrumIdentificationProtocol::fragmentTolerance > SpectrumIdentificationProtocol::parentTolerance > SpectraData::fileFormat > SpectraData::spectrumIDFormat > > I was thinking we could just turn these into CVParams or CVIDs. The latter case would make the > interface a little simpler, but would be a bigger change since it wouldn't allow the empty() member > call. > > Thanks, > -Matt > > > On 1/11/2011 4:20 PM, Robert Burke wrote: >> Hi Matt, >> >> Kudos to you for you approach! That's the way I was pushing for in the >> beginning and am excited to hear you did it. >> >> I agree on the ResultList concept. Should we keep the design discussion online? >> >> -RB > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > proteowizard-developer mailing list > pro...@li... > https://lists.sourceforge.net/lists/listinfo/proteowizard-developer > |