incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmuer <>
Subject Re: extending GraphNode with generics
Date Fri, 20 May 2011 11:20:33 GMT
On Fri, May 20, 2011 at 12:45 PM, Tsuyoshi Ito <> wrote:
> Hi
> I am using quite often subtypes of GraphNode in my projects for a
> specific domain. I have also seen Decorators/Wrappers of GraphNode in
> other projects. So, currently I don't see the benefit of the proposed
> change in clerezza. I think users should extend GraphNode for their
> specific needs - or what kind of subtypes do you propose for clerezza,
> Reto?
I'm not proposing anything. I just noted that because the would be
only 7 types that can reasonably be used as generic type argument to
GraphNode we could also have 7 subclasses. But again, my main point
was to understand what's motivating this issue. With the changes to
the scala DSL EasyGraph will bring we are making things easier for
users. For the generic graphnode I find it hard to see the situations
this would concretely save us from an ugly cast (seeing where the need
arises from would help compare the generic approach with other
alternatives like multiple getNode-methods or double-dispatch). But I
do see that using generics would require changes all over clerezza to
prevent compiler warnings.

I might be wrong, but my impression is that that this whole discussion
is motivated more by intellectual curiosity rather than by an actually
identified field of improvement. This doesn't mean things couldn't be
improved as a result of exploring this, but I don't think that the
improvement (in the best case) would save as more than a couple of
lines of code or a few type-casts in the whole of clerezza.


> cheers
> tsuy
> 2011/5/20 Reto Bachmann-Gmür <>:
>> I think it is very straight forward to add a generic type to graphnode. It needs
changing lots of code to prevent warning, in most cases i think we have to add a <?>
or <Resource>, the situation where we actually have a method declared to return an objetc
with a concrete type param are relatively seldom.
>> What motivates the change? Graphnode is a convenience object, where not all methods
are usable for every instance. Rather than having generics we could also just have 3 or 4
subtypes, in this cas we could not just have more concrete return types for getNode but also
have methods that only apply to a specifc type.
>> But again, seeing where you think the change would bring concrete benefits would
make it easier to discuss the proposal.
>> Cheers,
>> reto
>> ----- Original message -----
>>> On 20 May 2011, at 00:13, Tommaso Teofili wrote:
>>> > Hi all,
>>> > as discussed in CLEREZZA-537 it may be worth having GraphNodes use
>>> > generics to add something like "T extends Resource" parameter allowing
>>> > easiest subject type retrieving (avoiding useless casts, as said by
>>> > Henry); I plan to create a patch tomorrow so that anyone can review it
>>> > and we can discuss it (in a new issue).
>>> > Regards,
>>> > Tommaso
>>> +1 for me. Be interested to see how it works out.
>>> Henry
>>> Social Web Architect

View raw message