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/
