From: Maurizio Vitale (maurizio.vitale_at_[hidden])
Date: 2007-05-21 17:09:17
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