On 28/11/12 10:59, Damian Steer wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 25/11/12 14:19, Andy Seaborne wrote:
The obvious follow-through to me is that there should be classes
(final even), not interfaces, because they have strong equality
rules.
See also JEP-169 "Value Objects". [1]
So presumably terms would be value-ish. Ditto triple and quad.
Yes
I didn't quite understand the implications of [1] but the
object-as-value and structural equality makes sense. The JIT does go
good stuff with final classes but I recall mention that a single
implementation of an interface is treated as final and all the
optimzations get done. If another class is loaded of the same
interface, the JITting is undone and redone for virtual methods call.
As the basic RDFterms are simple structs, inlining does have a
significant part to play for tight loops.
That leaves the need for interfaces as being about to implement without
a common required jar.
Not quite as SLF4J does it as LoggerFactory is a class (which goes
looking for ILoggerFactory) but there again, no code changes for
swapping implementations.
Add factory-as-interface and you could compile against one jar and use a
completely different implementation at runtime.
Or runtime injection of dependencies (Guice) ...
Graph and dataset collection-ish or even just iterable? I keep an eye
the java lambda discussion, and it would be nice to fit with that. [2]
(although I'm sure I've read an much updated version of this) Stuff like:
graph.filter(...).groupBy(...).into(anotherGraph);
:-)
I think the main objective is to simply capture the RDF abstract syntax
and may useful things like prefixes.
.filter.groupBy is more like a presentation API issue to be built on
top. But if the basics needed can be added to PURR interfaces with too
much impact then fine.
(and the scala interface is nearly done!)
As for equals(), java collections seem to use a form of structural
equivalence and some even work as hash keys (nice, but ewwwww).
Yes - for nodes and triples and quads that should work.
Java collections get "interesting" as you have to promise not to change
them if used as hash keys. Add unmodifiableGraph (and stil promise to
mess with it directly). Parser do like to add triples to graphs so that
are mutable. Immutablity and equivalance relationships should not be
built into the lowest level IMHO. Graphs can be big.
For me, the principle of "start simple and iterate" applies; just having
the interfaces to see how useful they are would be a step forward.
Andy
Damian
[1] <http://openjdk.java.net/jeps/169>
[2]
<http://cr.openjdk.java.net/~briangoetz/lambda/collections-overview.html>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlC17qwACgkQAyLCB+mTtynaPgCeP6yK2BERomukW5F5f8+hYe3c
2lQAnjSElyKf/GGGExyye1+/DZRtNxaO
=5lsS
-----END PGP SIGNATURE-----
