Avery Ching commented on GIRAPH-31:

After "iterating" on it, given that we don't have a well defined use case for a 
sorted iterator and those apis I suggested are a little nasty, I think the 
prefer the following:

Each Vertex implementation should implement Iterable as you both suggest, but I 
think following the Java utils style of sorted or not feels the most natural.  
We can describe the iterating order via javadoc and we can have multiple Vertex 
implementation, i.e. SortedPrimitiveVertex, HashPrimitiveVertex, etc.  Somehow 
isSorted() feels a little yucky.  Examples from java utils Set implemetnations:

Iterator<E> iterator()  Returns an iterator over the elements in this set in 
ascending order.

Iterator<E> iterator() Returns an iterator over the elements in this set.

> Hide the SortedMap<I, Edge<I,E>> in Vertex from client visibility (impl. 
> detail), replace with appropriate accessor methods
> ---------------------------------------------------------------------------------------------------------------------------
>                 Key: GIRAPH-31
>                 URL: https://issues.apache.org/jira/browse/GIRAPH-31
>             Project: Giraph
>          Issue Type: Improvement
>          Components: graph
>    Affects Versions: 0.70.0
>            Reporter: Jake Mannix
>            Assignee: Jake Mannix
>         Attachments: GIRAPH-31.diff
> As discussed on the list, and on GIRAPH-28, the SortedMap<I, Edge<I,E>> is an 
> implementation detail which needs not be exposed to application developers - 
> they need to iterate over the edges, and possibly access them one-by-one, and 
> remove them (in the Mutable case), but they don't need the SortedMap, and 
> creating primitive-optimized BasicVertex implementations is hampered by the 
> fact that clients expect this Map to exist.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


Reply via email to