>> 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. Nice! > 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 me ;-) I use this stuff for example in: clear_(fsm_(m_src_container)) 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! > > michael 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 :( Thanks, Christophe _______________________________________________ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
