should anchorNode be hardcoded in TreeModel?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

should anchorNode be hardcoded in TreeModel?

Frank Sergeant
(Dolphin 4)

TreeModel>>nodeClass
     ^TreeNode

Since the above method has been added to TreeModel to answer the node class,
shouldn't it be used everywhere?  TreeNode is hardcoded in
TreeModel>>initialize rather than using the #nodeClass method.  Elsewhere,
the method is sent instead of hardcoding the class.  Perhaps there is some
reason to hardcode the anchor node but not other nodes?

TreeModel>>initialize
   ...
   anchorNode := TreeNode new.
 (versus)
   anchorNode := self nodeClass new.

By changing #initialize to use the second form, a subclass of TreeModel
could use a different node class without needing to override #initialize
(just by overriding #nodeClass), for example, I'm using SortedTreeNode so a
node can keep its children sorted.

What do you think?


  -- Frank
  [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: should anchorNode be hardcoded in TreeModel?

Blair McGlashan
Frank

"Frank Sergeant" <[hidden email]> wrote in message
news:lw2W5.183$[hidden email]...
> (Dolphin 4)
>
> TreeModel>>nodeClass
>      ^TreeNode
>
> Since the above method has been added to TreeModel to answer the node
class,
> shouldn't it be used everywhere?  TreeNode is hardcoded in
> TreeModel>>initialize rather than using the #nodeClass method.  Elsewhere,
> the method is sent instead of hardcoding the class.  Perhaps there is some
> reason to hardcode the anchor node but not other nodes?

I think it is probably an oversight. The "anchorNode" has a special status
(as the real root of all the application roots that are displayed in a tree
view), but I can't think of any particular reason why it should need to be
of a specific class. We'll investigate and fix in the next patch level if
appropriate, so thanks for the report.

Regards

Blair