You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The whole DotLabelable mechanism could do with a rethink - for example if your state enum cases have associated values (which mine do, and is an awesomely powerful feature of this approach) then you can't easily create the DotLabelable array (unless your associated values are something simple like strings).
The text was updated successfully, but these errors were encountered:
I understand it can be annoying but I don't see it as a big problem: you just have to provide a value of the type you declare. I'm happy to discuss other approaches but nothing else comes to my mind given the fact that the list of items used to generate the diagram has to be passed to the actual transition logic code in order for the diagram to be always up to date.
Here's an example from my project:
enumDynamic{case Normal
case Gentle
}enumStrength{case Normal
case Strong
case VeryStrong
}enumSquareNodeEvent:DOTLabelable{case Highlight(delay:Double, dynamic:Dynamic, strength:Strength)
// ...
staticletDOTLabelableItems=[Highlight(delay:0, dynamic:.Normal, strength:.Normal),
// ...
]varDOTLabel:String{switchself{case.Highlight:return"Highlight(delay, dynamic, strength)"default:return"\(self)"}}}
The whole DotLabelable mechanism could do with a rethink - for example if your state enum cases have associated values (which mine do, and is an awesomely powerful feature of this approach) then you can't easily create the DotLabelable array (unless your associated values are something simple like strings).
The text was updated successfully, but these errors were encountered: