chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Caruana <david.caru...@alfresco.com>
Subject Re: various small cleanups
Date Thu, 09 Sep 2010 15:24:14 GMT
+1

Dave

On 9 Sep 2010, at 15:47, Klevenz, Stephan wrote:

> ok, then I don't see an issue with that.
> 
> +1
> 
> Stephan
> 
> -----Original Message-----
> From: Florent Guillaume [mailto:fg@nuxeo.com] 
> Sent: Donnerstag, 9. September 2010 16:24
> To: chemistry-dev@incubator.apache.org
> Subject: Re: various small cleanups
> 
> On Thu, Sep 9, 2010 at 3:52 PM, Klevenz, Stephan
> <stephan.klevenz@sap.com> wrote:
>> Florent wrote:
>>> 3.
>>> ItemIterable.skipTo returns a new iterable. I'm used to skipTo methods
>>> that just modify the iterable in place (for instance the JCR
>>> RangeIterator.skip or JCR2 EventJournal.skipTo or Lucene Spans.skipTo
>>> and TermDocs.skipTo), and in the use cases I've seen it's no use
>>> creating a new object. Is it ok to change this?
>> 
>> to 3. I'm not sure if I understand correctly. The reason to return an iterable is
to allow dotted expressions to have some "from-to" semantic of a range: ItemIterable<CmisObject>
i = folder.getChildren().skipTo(2).getPage(3);
> 
> Returning an object for chained expressions is all right, but what I
> want to ensure is that the contract of the method allows it to return
> "this" after modifying its internal state, and to change the
> implementation to that effect to avoid constructing new objects every
> time.
> 
> Florent
> 
> -- 
> 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


Mime
View raw message