On Fri, May 20, 2011 at 12:45 PM, Tsuyoshi Ito <[email protected]> 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. Reto > > cheers > tsuy > > 2011/5/20 Reto Bachmann-Gmür <[email protected]>: >> 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 >>> http://bblfish.net/ >>> >> >> >
