>> I 'm pretty sure that, while this clearly should be a function for
>> phoenix, I would not like the syntax:
>> g1(arg1,arg2,arg3,arg4)&& g2(arg1,arg2,arg3,arg4).
> Placeholders would be great here. I find most of the time I only care
> about EVT or EVT and FSM. Having MSM defined placeholders with cool
> names like evt_ and fsm_ wouldn't be bad IMHO.
These already exist but you are proving me that they aren't used to
their full potential now.
> Also... shouldn't operator() return a bool for a guard? Then this just
> becomes a composition. If g1 and g2 are phoenix functions then (making
> up some new MSM placeholders):
> g1(evt_) && g2(evt_,fsm_)
> will result in the composed lazy functors and placeholders are now
> your friends.
> This also allows me to write full phoenix lambdas inline with the eUML
> which would be the cat's meow!
Yes, looks great! Actually, it would also be possible with today's
implementation, so that I don't know why I didn't do it yet. Shame on
I use this stuff for example in:
But I didn't think of generalizing this.
However, I'd still like to also have the possibility to write only g1
&& g2, treating g1 and g2 as terminals. The reason is that this way, I
am currently able to use the functor front end functors inside eUML,
which is quite nice. I'm pretty sure it'd be possible with phoenix too
and I'd avoid a regression.
> I like the way these discussions are going Christophe!
Me too! I have the hope the discussions on this list will deliver
something really cool.
Thanks for the great point!
Unfortunately, I didn't manage to get further on the first (blocking)
point yet :(
proto mailing list