
On May 21, 2007, at 4:13 PM, Eric Niebler wrote:
Steven Watanabe wrote:
AMDG
Eric Niebler <eric <at> boost-consulting.com> writes:
If you want to change both, a possibility would when (for if_) and unless (for not_). Interesting. All, any, when, and unless are not unreasonable. I know you retracted this suggestion in another message, but I want you to bring it up again when proto is under review. Naming is super-important, and I want more feedback on this issue. I'll remind you when the time comes.
Another possibility is to use separate namespaces proto::operators::or_ proto::control::or_
[snip]
IMO, eliminating the operators:: namespace would be better. This isn't half bad:
struct MyGrammar : control::or_< or_<_,_> , bitor_<_,_>
{};
But control::or_ is likely to be more common than or_ (the operator), so the Huffman coding is lousy. Gah, naming is hard! Opinions? Maurizio? Joel? Hartmut?
I think this is getting somewhere. I would focus on making this nice to read rather than cheap to type in, so I'm not too concerned with the number of characters in the string control::or_. I'm more concerned that: - the or_ part doesn't stand out. It comes after some other characters that the reader has to parse while reading. And those will be shared by all control::{and,or,if,not}_. If you have a deeply nested grammar full of control:or_, control::and_ and friends it might be difficult to tell what it means. - and the error message (because hopefully we get one) when somebody uses the (operators::) or_ at the grammar toplevel needs to be crystal clear. Because somebody will forget the namespace qualification sometimes. For a large number of somebody and sometimes. Would it be criminal to consider or_, and_, not_, if_ "namespaces" ? This way we can get something like: or_::match< or_< > bitor_<> > Clearly they cannot be real namespaces, otherwise the template (operator::)or_ would shadow it, hence the match template should be stuffed into the (operator)::or_ template, which may or may not work depending on the partial specializations needed. Even if it worked, seems very poor coding taste. But maybe there's some other way to allow the or_::match look and feel. Don't know. I'll probably be ashamed of this suggestion in a couple of hours. Regards, Maurizio