My thought was to implement the methods mentioned in the bug using the NiceIterator. and leave the create() as abstract so one could simply implement create() and be done. And with one simple method it could be impelemented in an anonymous class ala Map1.
Claude On Mon, Jun 22, 2015 at 10:48 PM, Andy Seaborne (JIRA) <j...@apache.org> wrote: > > [ > https://issues.apache.org/jira/browse/JENA-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14596710#comment-14596710 > ] > > Andy Seaborne commented on JENA-966: > ------------------------------------ > > Adding {{andThen(Supplier<Iterator<T>>)}} to {{ExtendedIterator}} > complicates the {{ExtendedIterator}} interface. Some of the > {{ExtendedIterator}} uses are in the visible graph SPI so this is not just > clearing up. > > Better to build around the concept of "iterators" and have an (extended) > iterator that provides the delay. i.e. a {{LazyIterator}} which internally > delays is cleaner IMO because it encapsulates the supplier in a class, not > a general interface. > > So minimal change: > {{public LazyIterator(Supplier<ExtendedIterator<T>>)}} rather than > LazyIterator being abstract with {{create()}}. {{Supplier<>.get()}} is > called when {{lazy()}} is called. Then have {{create() { return > supplier.get();} }}. > Fixing up {{LazyIterator}} is a point-wise issue, especially as > {{LazyIterator}} isn't currently in-use. > > I'm unclear about the idea of an epic for iterators in general. If it is > all (Extended)Iterators, it sounds like a major undertaking with wide > repercussions yet there is no obvious benefit driven by changes to a class > not in use. If the "epic" is for LazyIterator, I don't care. Or remove > LazyIterator from jena-core and take the code where it is wanted. > > ---- > > Minor observations: > > {{LazyIterator}} delays until first call, typically {{hasNext}] or > {{next}} ; {{andThen(Supplier<ExtendedIterator<T>>)}} delays only until > creation of the "andThen" step. That's not quite the same. (Note the > {{Supplier}} generic signature.) > > {{LazyIterator}} already has "andThen", but it's got the wrong signature, > so that leaves toSet and toList. > > If {{LazyIterator}} becomes concrete, then that needs fixing. As a > abstract class leaving toSet and toList ("terminal operations") to the > concrete implementation makes sense to me but if someone wants to make > {{LazyIterator}} concrete, they will be needed. Or extend > {{NiceIterator<T>}}. > > > > > LazyIterator > > ------------ > > > > Key: JENA-966 > > URL: https://issues.apache.org/jira/browse/JENA-966 > > Project: Apache Jena > > Issue Type: Bug > > Components: Core > > Affects Versions: Jena 3.0.0 > > Reporter: Claude Warren > > Assignee: Claude Warren > > > > LazyIterator is an abstract class. The documentation indicates that the > create() method needs to be overridden to create an instance. From this I > would expect that > > now LazyIterator(){ > > @Override > > public ExtendedIterator<Model> create() { > > ... > > }}; > > Would work however LazyIterator does not override: > > remoteNext(), andThen(), toList(), and toSet(). > > I believe these should be implemented in the class. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.4#6332) > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
