I have ExtendedIterator contract tests in the new test suite. So we should have reasonable test cover for the contract. That code is in the old new_test branch and will be in the new contract test branch soon. I you want I can send you the source to test your implementation with. This will mean adding junit-contracts as a dependency for your tests.
Claude On Fri, May 1, 2015 at 5:26 PM, [email protected] <[email protected]> wrote: > Yes, in that case, the change was no more than "extends Filter<T>" -> > "implements Predicate<T>". No other changes. > > You can take a look at what's going on at: > > https://github.com/apache/jena/pull/55 > > and please comment! As a Jena newbie, I need comments. {grin} > > --- > A. Soroka > The University of Virginia Library > > On May 1, 2015, at 12:19 PM, Claude Warren <[email protected]> wrote: > > > An example is: > > > > org.apache.jena.security.utils.RDFListSecFilter > > > > Which filters results based on user access and is used whereever a > RDFList > > (or an iterator on one) is returned . > > > > Claude > > > > On Fri, May 1, 2015 at 5:12 PM, [email protected] <[email protected]> > > wrote: > > > >> Oh, now I think I understand your point better. > >> > >> Yes, I have already trawled that code and worked over those reusable > guys, > >> and yes, you will certainly still be able to combine and reuse > Predicates > >> in the same way that you have used Filters. When I get this PR in, you > can > >> see some examples of that. > >> > >> A Java 8 Predicate is just an interface that looks much like Jena's > >> Filter, which can benefit from the -> lamda syntax and which is > designed to > >> fit into the Java 8 language APIs (e.g. for use with Streams). > >> > >> --- > >> A. Soroka > >> The University of Virginia Library > >> > >> On May 1, 2015, at 12:07 PM, Claude Warren <[email protected]> wrote: > >> > >>> We have a number of places where Filter objects are created and reused > >>> (usueally due to complexity or to reduce the code footprint in terms of > >>> debugging). Will it still be possible to define these complex filters > >> and > >>> use them in multiple places. > >>> > >>> The permissions system does this in that it creates a filter for > RDFNodes > >>> and then applies them to the 3 elements in a triple to create a single > >>> filter for triples. > >>> > >>> There are several cases like this. > >>> > >>> I will have to look at the permissions code to find a concrete example, > >> but > >>> I think this is the case. > >>> > >>> Claude > >>> > >>> On Fri, May 1, 2015 at 4:53 PM, [email protected] <[email protected] > > > >>> wrote: > >>> > >>>>> As for the Filter implementation..... will that be transparant to > >> filter > >>>> implementations? I assume so. > >>>> > >>>> I think this was in response to my question about Filter? > >>>> > >>>> If you mean that things that currently implement Filter (outside of > >> Jena's > >>>> own code) will not be greatly affected, then yes, so I would hope. I > >> will > >>>> @Deprecated Filter and its methods, but that seems to me to be all > that > >> is > >>>> needed for this first step. > >>>> > >>>> I should have a PR with this later today, when you can observe some > real > >>>> code and give me feedback. > >>>> > >>>> --- > >>>> A. Soroka > >>>> The University of Virginia Library > >>>> > >>>> On May 1, 2015, at 11:47 AM, Claude Warren <[email protected]> wrote: > >>>> > >>>>> I don't see any reason not to remove the Node functions. > >>>>> > >>>>> As for the Filter implementation..... will that be transparant to > >> filter > >>>>> implementations? I assume so. > >>>>> > >>>>> On Fri, May 1, 2015 at 4:16 PM, Andy Seaborne <[email protected]> > wrote: > >>>>> > >>>>>> (mainly for Claude - I did check jena-pemissions and didn't see any > >>>> usage) > >>>>>> > >>>>>> There are a bunch of deprecated statics in Node (the correct way is > to > >>>> use > >>>>>> NodeFactory) > >>>>>> > >>>>>> Node.createAnon() > >>>>>> Node.createAnon(AnonId) > >>>>>> Node.createLiteral(LiteralLabel) > >>>>>> Node.createURI(String) > >>>>>> Node.createVariable(String) > >>>>>> Node.createLiteral(String) > >>>>>> Node.createLiteral(String, String, boolean) > >>>>>> Node.createLiteral(String, String, RDFDatatype) > >>>>>> Node.createLiteral(String, RDFDatatype) > >>>>>> Node.createUncachedLiteral(Object, String, RDFDatatype) > >>>>>> Node.createUncachedLiteral(Object, RDFDatatype) > >>>>>> > >>>>>> It looks like they are not used by the jena codebase and are there > for > >>>>>> compatibility only. > >>>>>> > >>>>>> Any reason not to remove them? > >>>>>> > >>>>>> Andy > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> I like: Like Like - The likeliest place on the web > >>>>> <http://like-like.xenei.com> > >>>>> LinkedIn: http://www.linkedin.com/in/claudewarren > >>>> > >>>> > >>> > >>> > >>> -- > >>> I like: Like Like - The likeliest place on the web > >>> <http://like-like.xenei.com> > >>> LinkedIn: http://www.linkedin.com/in/claudewarren > >> > >> > > > > > > -- > > I like: Like Like - The likeliest place on the web > > <http://like-like.xenei.com> > > LinkedIn: http://www.linkedin.com/in/claudewarren > > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
