[Gephi-plugins] variable length/ modifiable lists as attribute values?

Mathieu Bastian mathieu.bastian at gmail.com
Tue Oct 4 08:16:14 CEST 2011

On Mon, Oct 3, 2011 at 4:28 PM, Chris Esposito <chris.esposito at gmail.com>wrote:

> Hi All,
>     I've been digging through the attribute API & implementation, as  I
> wanted to know what the limits and possibilities are for supporting variable
> length (i.e., ArrayList-like containers) lists as attribute values. In
> particular, I'd like to be able to add and delete values from a
> variable-length list that is itself an attribute value. The existing API has
> a lengthy list of attribute value types that it supports, including lists of
> Integers, lists of Strings, etc., each of which is implemented as it's own
> class derived from a base class (from memory, this is AbstractList).
> However, I've noticed 2 things in the implementation code:
> 1) the underlying data container for a list of values is declared as a
> 'protected final' generic array, which (if I understand this correctly)
> means that it can be assigned exactly once; the constructor does this
> assignment, so I take this to mean that once created, the size of the
> underlying 'list' array is fixed.

Yes the AbstractList<http://gephi.org/docs/toolkit/org/gephi/data/attributes/type/AbstractList.html>is
immutable. This is generally recommended (Item
15: Minimize mutability from Effective
and the implementation is very much like an Array. If you need to update the
list, you'll need to recreate a new array. Hopefully Java can copy arrays
extremely quickly.

> 2) While there is a method to retrieve an element from one of these arrays
> there is no method provided to change or set an element, even though you
> could range-check the index or catch the array bounds exception should one
> be thrown as a result of a bad index.
> Both of these restrictions / omissions strike me as curious enough that I
> think there may be reasons for them that aren't obvious at first glance. For
> example I've read that declaring arrays as final can provide some measure of
> thread-safety. Maybe there's some issues with serialization that I simply
> haven't found yet. Assuming both my (1) and (2) observations are correct,
> does anybody have any insight as to why these decisions were made?

It could appear as a limitation but at the end it's a better design. The key
is that we control what happens when you set the value, and that
is essential. For instance, when you set a value we trigger SET_VALUE
events, which can be used by other modules. That wouldn't be possible if
with a mutable list. However that doesn't mean that the ArrayList style is a
bad idea, but we would have to wrap the add/remove features of the list in
an API. For instance I can imagine additional list-specific functions in the
AttributeRow. When we added lists, we chose to keep the existing (simple)
get/set API and have immutable lists instead, but we considered both

> If I did my own new attribute value list type / implementation, would
> replacing the array with an ArrayList or CopyOnWriteArrayList cause problems
> somewhere?

I would advise not as it would be a fork of the existing module and avoid
sending essential events. However we could propose some improvements to the
AbstractList so it's easier to create new lists from existing values (copy
constructors and so on).


> Thanks,
> Chris
> _______________________________________________
> gephi-plugins mailing list
> gephi-plugins at lists.gephi.org
> http://gephi.org/mailman/listinfo/gephi-plugins
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gephi.org/pipermail/gephi-plugins/attachments/20111003/72289387/attachment.html>

More information about the gephi-plugins mailing list