[
https://issues.apache.org/jira/browse/JENA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15075095#comment-15075095
]
ASF GitHub Bot commented on JENA-1083:
--------------------------------------
Github user ajs6f commented on the pull request:
https://github.com/apache/jena/pull/110#issuecomment-168017775
Well, this branch is clearly not worth rebasing post #115, and I haven't
run a profiler on it anyway. I'll take a look at `TripleOps` and think a little
more about the problem.
I completely agree with your assessment, especially "At some point,
somewhere there is going to be some fiddly bit of code to do reordering." My
aim is for there to be only _one_ fiddly bit per reordering, for more clarity
and maintainability and less chance of error. Right now code like
'TripleTableForm` and `QuadTableForm` have many places where exactly the same
reordering logic is repeated, with only a method name difference. It's hard for
me to believe that there isn't a better way to do this. I just need to find one
that doesn't incur extra expenses while working with Java's single-valued
functions. I've tried by packing values into objects and then into arrays, so
I've got to find some other way.
> 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)
