[ 
https://issues.apache.org/jira/browse/COMMONSRDF-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14503638#comment-14503638
 ] 

Reto Gmür commented on COMMONSRDF-17:
-------------------------------------

Thanks for the pointer.

The discussion there seem to base on the wrong assumption that the collections 
API restrict to 2G triples. 

This issue is not about adopting the Collections API but only to be compatible 
with it, so that implementations can implement it. It is true that add(Triple) 
and remove(Triple) are incompatible too. We could move to another name as to 
allow implementation of the less efficient Collections methods as, e.g.:
{code}
public boolean add(Triple t) {
  if (contains(t)) {
    return false;
  } else {
    fastAdd(t);
    return true;
  }
}
{code}

> Size method
> -----------
>
>                 Key: COMMONSRDF-17
>                 URL: https://issues.apache.org/jira/browse/COMMONSRDF-17
>             Project: Apache Commons RDF
>          Issue Type: Improvement
>            Reporter: Reto Gmür
>
> The size method is problematic for two reasons:
> - it is incompatible with the Collections-API, implementations cannot at the 
> same time implement Collection<Triple> (even though a Graph is a collection 
> of triples).
> - With some types of implementations calculating the exact size of a graph 
> can be very expensive and often the client just requires an approximate size
> So I propose to replace the size method with the following
> [- size: int: same as in Collection.size (returns Integer.MAX_VALUE for 
> bigger graphs) ]
> - exactSize: long: the exact size
> - approximateSize: long: the approximate size
> For all but exactSize the interface can provide default implementations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to