>
>
> > I don't fully understand the TreeModel example, what would your tool do
> with all the men/displayBlock/childrenBlock ... - methods?
>
Ah, I should've explained what TreeModel is; it is a Spec UI widget to
display tree-like structures:
So the way this works is that I give the TreeModel some root object (DCFsm)
and then blocks that describes some behavior.
So in childrenBlock: [ :parent | ... ] the block is expected to return
child elements for the parent.
In displayBlock: you pass a block that returns the label that you will
see.. e.g. [ :anObject | anObject name , ' (' , anObject class name , ')' ]
iconBlock: returns the icon for the object and so on and so forth.
So the way I have implemented it right now is something like
~~~~~~~~~~~~~~~~~
childrenFor: anObject
| col name |
name := anObject class asString asSymbol.
col := OrderedCollection new.
name = #DMMindMap
ifTrue: [ ^ col ].
(anObject isKindOf: DCDiagram)
ifTrue: [ col addAll: anObject elements ].
(anObject isKindOf: DCNamedElement)
ifTrue: [
name = #BormParticipant
ifTrue: [ col addAll: anObject nodes ].
name = #BormActivity | (name = #BormState)
ifTrue: [ col addAll: anObject outgoing ].
name = #BormActivity
ifTrue: [ col addAll: anObject sent ].
name = #BormCommunication
ifTrue: [ col addAll: anObject dataFlows ].
name = #BormCommunication
ifTrue: [
anObject hasConstraint
ifTrue: [ col add: anObject constraint ] ].
name = #BormTransition
ifTrue: [
anObject hasConstraint
ifTrue: [ col add: anObject constraint ] ] ].
^ col
~~~~~~~~~~~~~~~~~
Which is unreadable, unmaintainable and nonextensible. All the #Borm*
symbols actually refer to classes of a completely independent package and
repository which doesn't even need to be loaded in the system.
I think what Peter means is: the object oriented way to handle different
> types is by dispatching on each type (~ double dispatch, ~ visiting). You
> could need this for different aspects of your application. In the end, the
> same core mechanism will be implemented multiple times. Sadly, minor
> semantics/structural differences will make it hard to abstract this out.
Yes, double-dispatch seems like the apt solution, however it would lead to
NxM number of classes (as mentioned before). But the more I think about it
the more I feel that I will not get any better than that.
Peter
