Re: What can be removed/simplified ?

Andy Seaborne Thu, 30 Apr 2015 13:14:45 -0700

On 29/04/15 20:58, Andy Seaborne 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()


which leaves:

    boolean sizeAccurate();
    boolean addAllowed();
    boolean deleteAllowed();
    boolean iteratorRemoveAllowed();
    boolean canBeEmpty();

Is it better to have

  isReadOnly()

and not addAllowed(), deleteAllowed()

I can imagine append-only graphs but is it worth having two calls whenthe common case is read-only vs writable.


And if it is just

    boolean sizeAccurate();
    boolean isReadOnly();
    boolean iteratorRemoveAllowed();
    boolean canBeEmpty();

Should we just pull these up into Graph/GraphBase?

I have only found two uses of Capabilities in non-test, non-passing-oncases. I didn't find any evidence of passing capabilities around.

One use of getCapabilities() in the isomorphism tester GraphMatcher - itneeds sizeAccurate()).

One use in RDF/XML output; Abbreviated uses findContractSafe but itprints a warning if used and no one has asked about that in a long whileso I'm guessing it does not happen any more.


Strangely - I can't find uses of iteratorRemoveAllowed() except in tests.

        Andy


     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.

Re: What can be removed/simplified ?

Reply via email to