That doesn't really sound object oriented... We should discuss this later with some use cases.
Florian -----Original Message----- From: Florent Guillaume [mailto:[email protected]] Sent: Mittwoch, 12. Mai 2010 15:35 To: chemistry-dev Subject: Re: [jira] Resolved: (CMIS-124) Client Runtime Implementation I know but it's rather easy to add all of: T getMinValue(); T getMaxValue(); BigInteger getMaxLength(); DecimalPrecision getDecimalPrecision(); DateTimeResolution getDateTimeResolution(); on the single PropertyDefinition class, and make them throw exceptions when not called on the suitable kind of property. Florent On Wed, May 12, 2010 at 3:20 PM, Florian Müller <[email protected]> wrote: > Hi Florent, > > The Property*Defintion interfaces are actually different and cannot be > collapsed. Compare PropertyDateTimeDefinition with PropertyDecimalDefinition, > for example. > > > - Florian > > -----Original Message----- > From: Florent Guillaume [mailto:[email protected]] > Sent: Mittwoch, 12. Mai 2010 14:49 > To: chemistry-dev > Subject: Re: [jira] Resolved: (CMIS-124) Client Runtime Implementation > > Yes, with use there's some things that may appear as suboptimal in the > current API and we cannot promise no changes. But nothing > revolutionary will come I'm sure. > > As an example of changes that may or may not appear: > > I don't like this part of the high-level API and find it hard to use: > <T> T getPropertyValue(String id); > <T> List<T> getPropertyMultivalue(String id); > > After the first release is done, I'll propose to change it to: > <T> T getPropertyValue(String id); > > Which would returns a single value for a single-valued property, and a > list for a multi-valued property. > > > I'd also like to fold all the PropertyDecimalDefinition, > PropertyStringDefinition, etc. into the single PropertyDefinition<T> > because the sub-interfaces don't add much IMHO. Proposal to come. > > > (I'm not proposing to do it earlier as I really want a first release > out the door and have little enough time to work on this right now... > and I'm in vacation for the next 10 days.) > > Florent > > > > On Sun, May 9, 2010 at 6:52 PM, Florian Müller <[email protected]> wrote: >> Hi Ugo, >> >> "Somewhat stable" is the right term. Most of the merger refactoring tasks >> are done. Only the type manager implementation is still missing. >> >> I cannot promise that there will no changes within the next weeks, but we >> certainly will not redesign the API. >> >> >> - Florian >> >> >> -----Original Message----- >> From: Ugo Cei [mailto:[email protected]] >> Sent: Freitag, 7. Mai 2010 19:18 >> To: [email protected] >> Subject: Re: [jira] Resolved: (CMIS-124) Client Runtime Implementation >> >> >> On May 7, 2010, at 3:44 PM, Florian Müller wrote: >> >>> Hi Ugo, >>> >>> It's there for quite some time now. >>> >>> This page explains how you get and compile it: [1] >>> The API introduction pages [2] and [3] are a bit out-of-date. The basics >>> are still valid but some names have changed. >> >> >> Thank you. What I actually would like to know is whether the current APIs >> are considered somewhat stable, after the Chemistry/OpenCMIS merge. I can >> live with an incomplete and buggy implementation (and try to contribute >> fixes, as much as possible), but less so if a complete redesign is still in >> the pipeline. >> >> Ugo >> >> -- >> Ugo Cei >> Sourcesense - making sense of Open Source: http://www.sourcesense.com >> >> > > > > -- > Florent Guillaume, Director of R&D, Nuxeo > Open Source, Java EE based, Enterprise Content Management (ECM) > http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87 > -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
