[
https://issues.apache.org/jira/browse/JENA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103952#comment-15103952
]
ASF GitHub Bot commented on JENA-1083:
--------------------------------------
Github user afs commented on the pull request:
https://github.com/apache/jena/pull/120#issuecomment-172391107
This is now quite inconsistent. There too many names and both locations
and naming are mixed up.
Let's simplify for jena-base. What you call things in the "mem" package is
your choice.
In tuple(t) and function(f) we now have:
TetraConsumer (f), TetraFunction (f), Consumer4 (t), TetraOperator(t),
TriConsumer(t), TriFunction(t), TriFunction.TriOperator(t).
TriConsumer.Consumer3(t)
The common naming from other systems like fj (Functional Java), scala is
numbering "F" and "Function4" etc - it's also aligned to the naming of Tuple
implementations. Let's use that style and so we do not have concept clashes
with RDF. Java has got itself into a bit of a hole on naming and from the
consequences of erasure - no need to be restricted by that.
**Proposal 1:**
In package tuple:
```
@FunctionalInterface
interface TFunction4<X> { void apply(X x1, X x2, X x3, X x4) ; }
```
and
```
@FunctionalInterface
interface TConsumer4<X,Z> { void accept(X x1, X x2, X x3, X x4) ; }
```
same for `TFunction3` and `TConsumer3` and only these.
It's not a function on a tuple so not `TupleFunctionN`. `T` keeps away
from any future clash with `Function4`, `Consumer4`. We can put discussion of
those elsewhere - not needed for this PR.
**Proposal 2:**
Have `function/Function4`, `function/Consumer4`.
These are the only ones. No Tuple-related all same X forms.
If package core/mem wants alias/specializations (and it does not really
save very much) it can have them locally, maybe even short names like `F4<X,Z>`
for `Function4<X,X,X,X,Z>`.
I much prefer proposal 1 and want leave "function" for a different
discussion.
**Other**
If you want to add lots of `final` in core/mem, so be it. It's almost
clutter and the compiler does calculate effectively final nowadays.
In particular, no final on interface parameters. The word is ignored, it
does not take part in signature matching and it is not enforced in
implementations.
> 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)
