Re: [boost] [msm] eUML guard/action location

Subject: Re: [boost] [msm] eUML guard/action location
From: Michael Caisse (boost_at_[hidden])
Date: 2009-12-07 18:24:28

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