I'm a long-time user of Jena, but entirely new to its internals, so this may be a very off-the-mark opinion, but perhaps org.apache.jena.util.iterator.Map1 could be swapped out for java.util.function.Function?
--- A. Soroka The University of Virginia Library On Apr 30, 2015, at 10:39 AM, Andy Seaborne <[email protected]> wrote: > On 30/04/15 07:20, Claude Warren wrote: >> While we are at it I would like to see that restriction that requires >> Grahp.getStatisticsHandler() to return the same instance every time >> removed. It makes proxies much more difficult. > > Makes sense. > > (I would note that statistics for anything involving 2 out of 3 of the args > are not provided by any graph that I can find). > > Andy > >> >> On Wed, Apr 29, 2015 at 8:58 PM, Andy Seaborne <[email protected]> wrote: >> >>> On 29/04/15 18:17, Claude Warren wrote: >>> >>>> I use the following: >>>> >>>> addAllowed() is used by contract tests to determine if triples can be >>>> added. Also, permission system sets this based on the users permissions. >>>> canBeEmpty() is used by the contract tests to determine if the deleteAll >>>> methods should return an empty graph. >>>> >>> >>> When is this ever false? Inference graphs? >>> >>> (This is not used in the current codebase as far as I can see) >>> >>> deleteAllowd() same use as addAllowed() >>>> iteratorRemoveAllowed() -- this is handy to know before the remove is >>>> attempted. >>>> >>> >>> This isn't honoured everywhere IIRC. You're only looking in jena-core. >>> >>> sizeAccurate() -- this is used by the contract testing to determine if >>>> delete and add should alter the number of records reported. I am also >>>> looking at adding some hash joining capabilities and knowing if the sizes >>>> are accurate may make a difference. But that is all future stuff. >>>> >>> >>> FYI: >>> https://github.com/afs/quack >>> >>> These I don't use and can see being removed: >>>> >>>> findContractSafe() -- I don't know what this one means and have never used >>>> it. >>>> handlesLiteralTyping() -- This was used but obviously sine all graphs now >>>> have to support literal typing this can be removed. >>>> >>> >>> and presumably not addAllowed(boolean), deleteAllowed(boolean) >>> >>> (I find the boolean form unhelpful because they don't say what triples can >>> and can not be add/deleted.) >>> >>> so let's try removing: >>> >>> addAllowed(boolean) >>> deleteAllowed(boolean) >>> findContractSafe() >>> handlesLiteralTyping() >>> >>> >>> Andy >>> >>> >>>> On Wed, Apr 29, 2015 at 4:14 PM, Andy Seaborne <[email protected]> wrote: >>>> >>>> On 29/04/15 16:04, Claude Warren wrote: >>>>> >>>>> I have no problem retiring FileGraph >>>>>> >>>>>> Capabilities is another issue. I have used it and it is used in several >>>>>> places in the contract tests where we have to know if the graph supports >>>>>> transactions and the like. I find it useful. In addtion the >>>>>> information >>>>>> containd in the capabilities is often not easily discoverable (if at >>>>>> all). >>>>>> >>>>>> >>>>>> Transactions aren't in the Capabilities interface. >>>>> >>>>> Which aspects of the Capabilities interface? Some looks to be out of >>>>> date >>>>> (findContractSafe); some are not the right question >>>>> (handlesLiteralTyping) >>>>> >>>>> Andy >>>>> >>>>> >>>>> >>>>> >>>>>> On Wed, Apr 29, 2015 at 9:45 AM, Andy Seaborne <[email protected]> wrote: >>>>>> >>>>>> Claude's email about FileGraph prompted me to think for Jena3: >>>>>> >>>>>>> >>>>>>> What can be removed? >>>>>>> What can be simplifed? >>>>>>> >>>>>>> Even while keeping the current APIs, there is going to stuff that isn't >>>>>>> used, isn't used much, or even gets in the way. For maintainability, >>>>>>> effectively unused features are noise and risk needing to maintain >>>>>>> contracts that users don't actually use. >>>>>>> >>>>>>> Some things that come to mind in jena-core: >>>>>>> >>>>>>> FileGraph [*] >>>>>>> Capabilities >>>>>>> GraphTransactionHandler >>>>>>> >>>>>>> and with advocacy: >>>>>>> >>>>>>> RDFReaderF, RDFWriterF (with RIOT integration; caution for RDF/XML) >>>>>>> >>>>>>> Some places where interfaces don't seem to add anything: >>>>>>> >>>>>>> LiteralLabelImpl >>>>>>> >>>>>>> (actually the whole LiteralLabel thing is worth looking at - maybe we >>>>>>> can >>>>>>> pull the whole thing into into Node_Literal itself) >>>>>>> >>>>>>> AnonIds - maybe leave in the RDFAPI (they cross the boundary) but >>>>>>> internall bNodes can be a couple of longs for their state (a UUID in >>>>>>> other >>>>>>> words, not a UID). >>>>>>> >>>>>>> Andy >>>>>>> >>>>>>> [*] >>>>>>> In Java8, the app, or library code, could do this better as: >>>>>>> >>>>>>> update(()->{ >>>>>>> ... graph changes ... >>>>>>> } >>>>>>> >>>>>>> and update() does the on-disk backup stuff. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> >
