Re: [boost] [proto] new version, breaking changes

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