Christophe Henry wrote:
Hi Michael,
I just remembered the last reason for the current eUML syntax: CurrentState() + cool_event() = DestState() [Guard()]/(action())
It is that eUML row actions/guards can become quite long (something like adjacent_find_(...) ) and I was having difficulties keeping the rows readable. Concretely, I often had to keep the target state on a line by itself, which was costing a line of my screen. With the current syntax, you can get it easier:
CurrentState() + cool_event() = DestState() [VeeeeeryLoooooooooongGuard()] /(LooooooooooooooooongAction())
instead of:
CurrentState() + cool_event() [VeeeeeryLoooooooooongGuard()] /(LooooooooooooooooongAction()) = DestState()
For the tranquility of my conscience, are you still sure you prefer the more logical syntax?
Christophe _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Christophe - Ah... very good point. I've been doing a lot of Spirit/Qi work this past year and I can tell you the source code formatting makes all the difference in the world. I would likely just use copious white space: CurrentState() + cool_event() [VeeeeeryLoooooooooongGuard()] /(LooooooooooooooooongAction()) = DestState() That would keep the alignment looking the same. I think you raise a very important consideration for something like eUML. Not only should the syntax make sense but the code when written should provide some representation of the intent. Does that look any better or worse than this? CurrentState() + cool_event() = DestState() [VeeeeeryLoooooooooongGuard()] /(LooooooooooooooooongAction()) Not in my opinion. I can imagine trying to teach a session on MSM and using eUML. I think the more logical syntax will be more quickly adopted. Just my thoughts. Thanks for asking. michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com