Re: [boost] [log] Comments

Subject: Re: [boost] [log] Comments
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2010-03-16 14:44:08

AMDG

Andrey Semashev wrote:
> On 03/16/2010 08:35 PM, Steven Watanabe wrote:
>> Andrey Semashev wrote:
>>> Technically, it is possible to merge the filter and formatter into a
>>> single class. However, this looks like a bad design to me, since the
>>> attr usage syntax becomes ambiguous in different ways, and its
>>> implementation includes two different and unrelated things.
>>
>> How is it ambiguous? I don't like having to refer to the
>> same thing by different names depending on how I'm
>> going to use it. You should be able to determine how
>> to treat the attr from the context that it's used in.
>
>   attr< int >("X", "%04x") > 10
>
> Is that a formatter or a filter? If attr was a lambda placeholder, as 
> you suggest, this expression would probably compile, until being 
> assigned to a variable or being invoked either way.

Why does it have to compile?  The obvious implementation
would be for this attr to produce a string when invoked, which
obviously cannot be compared to an int.  Anyway, this seems
like yet another reason to remove Boost.Format from the attr
function.

> Also, if attr was polymorphic, would this compile:
>
>   function< bool (attribute_values_view const&) > f =
>     attr< int >("X");
>
> ?
>
> That shouldn't compile, assuming that attr< int >("X") is a formatter 
> (because the signature differs) or a filter (because that filter is 
> incomplete).

I would expect this to compile, but issue a warning about converting
int to bool.  This conversion is a general problem of C++.  I don't
see that you gain much by forbidding it.

>>> That approach could probably be reasonable in a general-purpose lambda
>>> library, but filters and formatters, as they are now, are quite
>>> specialized (which is not bad).
>>
>> This specialization is bad if it forces you to have separate attrs.
>
> From their implementation standpoint, they have nearly nothing in common.

Then all the sophisticated implementation doesn't belong in attr.
It belongs in the whole formatter/filter object.

> You mean, like this:
>
>   bind(begins_with, bind(attr< std::string >("Tag"), _1)), "Important")
>
> ?
>
> Compared to my syntax, this looks cryptic, to say the least.

No I meant, begins_with(attr<std::string>("Tag"), "Important").
I don't understand why you think that random extra stuff
is needed just because a member function is turned into
a non-member.  FWIW, the bind syntax would mostly work as is with
no extra work from you, if attr just returned a function object,
so I don't think it's necessarily a bad thing, since I really do not
like to see you reinventing the wheel in so many places.

>> Have you measured the effect? Oh, I see what you mean. I
>> would have no problem if you dropped the format parameter
>> of attr entirely.
>
> But I don't want to drop it. It's quite useful.

You can already use Boost.Format at the top level.
 From what you've said, this use of Boost.Format
conflicts with things that I consider much more
important.

In Christ,
Steven Watanabe