[
https://issues.apache.org/jira/browse/JENA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15072843#comment-15072843
]
ASF GitHub Bot commented on JENA-1083:
--------------------------------------
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/110#issuecomment-167593138
1. I totally understand that changing `Triple` and `Quad` is significant,
so that caution is the order of the day.
2. I'm not sure of what you mean by the "compiler implications". I think
that what's in this PR is just as typesafe as what is in `master` now without
any more overhead, but I'm happy to correct any examples that pop up. We could
get rid of the extra slots by offering a fixed-size tuple constructor
`Tuple(byte size, T... elements)`, which might be nice anyway.
3. I don't understand how the notions of equality are different here, but I
haven't thought as much about triples as have you. Only two `Triple`s with the
same subject, predicate and object are equal now, and only two such triples are
equal in this PR. (More or less the same for `Quad`s.) I've added a commit to
show that. Am I missing something about how two `Triple`s could be `equal` when
they aren't equal as `Tuple`s? I was careful to fix subject, predicate and
object to _specific_ components of the `Tuple` (`0`, `1`, and `2`). I don't
think this PR can generate problems with triples with different orders of
components.
4. I actually find `nodes[1]`, etc. much clearer than `first`, etc.,
because the numbers help me understand what is going one, but I think that's a
matter of personalities, so it's no argument in favor of the PR.
Basically, since `ColumnMap` is designed to work with `Tuple`s only, I did
this in order to use it without incurring lots of extra object creation. If we
don't go that road, cool, I'll look at creating something like `ColumnMap` but
targeted at `Triple` and `Quad`.
> MInor refactoring in TupleTables
> --------------------------------
>
> Key: JENA-1083
> URL: https://issues.apache.org/jira/browse/JENA-1083
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ
> Reporter: A. Soroka
> Priority: Minor
>
> There are some minor refactorings available for TupleTable and its subtypes,
> particularly PMapTripleTable and PMapQuadTable that will clarify their use.
> Specifically, current impls of those abstract types have to override several
> methods for adding, removing, and finding tuples. In fact, the only
> information being added when those methods are overridden is conversion
> between canonical and internal tuple ordering. This refactoring is to provide
> methods that do that conversion and nothing else, which will make two methods
> the most that any implementation of those abstract classes will have to
> provide.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
