Subject: Re: [boost] Assign V2 - first impression
From: er (er.ci.2020_at_[hidden])
Date: 2011-06-24 11:09:31
On 6/24/11 9:08 AM, Stewart, Robert wrote:
> er wrote:
>>
>>> I am sure that it is a powerful library, but I really have no
>>> idea at all what is going on. I can't even parse the first
>>> line as valid C++ in any way. You need better examples, and
>>> also is that really the best way you could find to express
>>> repeating?
>>
>> If I try to imagine what the interface would look like after
>> taking into account some of the suggestions that were made, this
>> sentence:
>>
>> "Create data elements by mapping 1, 10, 100, 1000 by function
>> f, and insert each result in cont by invoking modifier
>> push_front."
>
> If I interpret that correctly, it would be clearer as:
>
> "Create elements in cont, using push_front(), by calling f() 1, 10, 100, and 1000 times."
>
Noted, thanks.
>> translates to
>>
>> (
>> push_front<1>( cont ) % ( _data = f ) % ( _repeat = n )
>> )( 1, 10, 100, 1000 );
>
> Why the leading underscores on "_data" and "_repeat?"
It's part of a set of conventions that are pervasive throughout the
library: trailing underscore for types, leading one for const objects:
const name_ _name = {};
Names without underscores are reserved for functions.
>
>> Questions :
>> - is it more readable, now?
>> - What if each example was preceded by its English equivalent.
>
> Preceding each by a clear English equivalent is necessary.
Noted.
>
> Could that code be spelled like the following instead?
>
> push_front<1>(cont).from(f).repeated(1, 10, 100, 1000);
>
> That is, instead of operator overloading, member functions would make things clearer and more succinct. Is there more to the operator
overloading than I know making the member function approach too
restrictive? What happens to your operator overloading approach when a
To use a proverbial expression, the member function approach is "carved
in stone", if you like. Not using operator%. I'm going to assume that
'object' is returned by put( cont ) or deque<T>( _nil ). It doesn't
matter which, since they rely on the same implementation. Consider
( object % option1 % ... % optionn )(1, 10, 100, 1000);
object has two (orthogonal) components : the data-generator, which maps
arguments to a data-element, and the modifier which takes care of
inserting that data-element. Each option modifies either of these two
components. For example
( object % ( _data = f ) )( 1, 10, 100, 1000 );
changes the data-generator to f. For example,
( object % ( _repeat = n ) )( 1, 10, 100, 1000 );
wraps a new modifier around the one that already resides in object (say
push_back), such as to invoke it n times.
While this is perhaps not as intuitive as desired, it's in my view an
irreducible price to pay to have modularity and open for extension : one
can customize an option.
I anticipated that this would be a problem and already provided some
remedy (I won't delve on it), but did not push the reasoning far enough.
The next step, I think, is to try to get back to functions, as you
suggest, but free functions, not member functions. I already proposed a
new syntax. Let me repeat it:
push_front<1>( cont )( 1, 10, 100, 1000 );
would be equivalent to the less eye candy
( put<1>( cont ) % _push_front )( 1, 10, 100, 1000 );
Consequently, using the first form, the use of operator% would appear,
only for additional options:
( push_front<1>( cont ) % ( _data = f ) % ( _repeat = n ) )( 1, 10,
100, 1000 );
One way to see that being able to encapsulate an option as an object is
a good thing, however, is to imagine to have to write two unit tests:
void unit_test1()
{
std::deque<T> v;
v.push_back( T( args1... ) ); ...; v.push_back( T( argsn...) )
// whatever
}
void unit_test2()
{
std::deque<int> v;
v.push_front( T( args1... ) ); ...; v.push_front( T( argsn...) )
// whatever
}
With V2, you can do the same like this:
template<typename Option>
void unit_test(Option option)
{
std::deque<int> vec;
( put( vec ) % option )( args1... )...( argsn... );
// whatever
}
unit_test( _push_back );
unit_test( _push_front );
Some people might find this contrived. Fair enough, but it's meant to
make a point about modularity, which should have some benefit in less
contrived situations.
HTH, and thanks for your interest.