Thanks for the replay; I had failed to see that post yesterday when searching 
about this.

Reading the discussion brought up a related question:

If a vertex is to have "state", is it better to store this in an extended 
vertex value object or as member variables of the class and override the 
readFields and write methods for the vertex?

(Note that the second option isn't possible at the moment, since the only 
extendable vertex types have those methods finalized.)  And a related question:

In the life a vertex, is it ever instantiate without either using the 
readFields (which can restore the member variables) or the vertex reader class 
provided by the user (where the user can set the member variables)?

If there are other ways in which a vertex is instantiated, it would be good to 
know about, for the above reason.

Thanks,
Nick

On Aug 1, 2012, at 11:07 AM, Alessandro Presta wrote:

Hi Nick,

Thanks for pointing this out.
Here's a relevant discussion that was just recently started: 
https://issues.apache.org/jira/browse/GIRAPH-272.
Hopefully we get this sorted out soon.

Alessandro

From: Nick West 
<nick.w...@benchmarksolutions.com<mailto:nick.w...@benchmarksolutions.com>>
Reply-To: "user@giraph.apache.org<mailto:user@giraph.apache.org>" 
<user@giraph.apache.org<mailto:user@giraph.apache.org>>
Date: Wednesday, August 1, 2012 3:48 PM
To: "user@giraph.apache.org<mailto:user@giraph.apache.org>" 
<user@giraph.apache.org<mailto:user@giraph.apache.org>>
Subject: package-private methods in Vertex/BasicVertex

Hi,

There are several methods in Vertex/BasicVertex that are declared as abstract 
but without any access modifier specified.  They are:

    abstract void putMessages(Iterable<M> messages);
    abstract void releaseResources();

This has the effect that they both have the access modifier package-private.  
The effect of this is that only classes in the giraph package that extend 
Vertex can override the method.  Specifically, any Vertex implementation not in 
the giraph package cannot override these methods.

Is this the intended behavior?  I think an easy fix would to be to explicitly 
declare them as protected, which would allow classes outside of the package to 
override these methods.

I've looked into using several of the other predefined vertex types 
(EdgeListVertex, HashMapVertex, etc), which override these methods. However, in 
these classes the write and readFields methods are declared final, limiting the 
amount of customization one can make to these classes.

If you have any alternative suggestions, I'd be happy to hear them.

Thanks,
Nick West

Benchmark Solutions
101 Park Avenue - 7th Floor
New York, NY 10178
Tel +1.212.220.4739 | Mobile +1.646.267.4324
www.benchmarksolutions.com <http://www.benchmarksolutions.com/>
<image001.png>





<image001.png>


Nick West

Benchmark Solutions
101 Park Avenue - 7th Floor
New York, NY 10178
Tel +1.212.220.4739 | Mobile +1.646.267.4324
www.benchmarksolutions.com <http://www.benchmarksolutions.com/>
[cid:image001.png@01CCA50E.43B4A860]





<<inline: image001.png>>

Reply via email to