And gmail didn't add the image correctly it seems...
On Thu, Jun 18, 2015 at 10:10 AM, Peter Uhnák <i.uh...@gmail.com> wrote:
>
>> > 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
>
