incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Story <henry.st...@bblfish.net>
Subject Re: RichGraphNode
Date Wed, 16 Mar 2011 21:21:21 GMT

On 16 Mar 2011, at 20:51, Reto Bachmann-Gmuer wrote:

> 
> Perhaps, but then sometimes the new constructor is easier than an import statement.
> I found it a bit odd in some code to create an import statement for this.
> I didn't notice the auxiliary constructor wasn't there before. It's certainly good to
have, but as RichGraphNode is a decorator for GraphNode the primary constructor should remain
as it is.


Ok so the reason I put those "TODOs" in there which should perhaps have been QUESTIONS:
is that It seems to be silly to have the primary constructor be one that requires one to create
an object that then gets deconstructed, as we see here:

class RichGraphNode(node: GraphNode) extends GraphNode(node.getNode, node.getGraph) {

because if that is the primary constructor then even a secondary constructor that took a node
and a graph would need to pass that to the primary constructor, which would then immediately
discard the created object. Rather it would be better to have

class RichGraphNode(node, graph) extends GraphNode(node, graph) {
 
  def this(node: GraphNode) = this(node.getNode, node.getGraph)
...
}

> 
> Next step is to document the class....
> If you're TODOs indicate that there will be a documentation very soon, then I've less
strong feelings against them ;)

Yes, I was just trying to understand the code...

Henry


Social Web Architect
http://bblfish.net/


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message