Re: [boost] New Library Proposal: dual_state

From: Jost, Andrew (Andrew_Jost_at_[hidden])
Date: 2005-07-14 20:50:36

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Rob Stewart
> Sent: Thursday, July 14, 2005 9:53 PM
> To: boost_at_[hidden]
> Cc: boost_at_[hidden]
> Subject: Re: [boost] New Library Proposal: dual_state
> 
> From: "Jost, Andrew" <Andrew_Jost_at_[hidden]>
> > From: boost-bounces_at_[hidden]
> > [mailto:boost-bounces_at_[hidden]] On Behalf Of Rob Stewart
> > > From: "Jost, Andrew" <Andrew_Jost_at_[hidden]>
> > > > > From: boost-bounces_at_[hidden] 
> > > > > [mailto:boost-bounces_at_[hidden]] On Behalf Of Fernando 
> > > > > Cacciola
> > > > 
> > > > Here is a real example.  Imagine a researcher with many 
> > > > instruments
> > > > 
> > > > Okay.  This works, but what about that ugly call to loadPoint?  
> > > > The problem is that the library function is expecting a signal
> > > value, not
> > > > a Boost.Optional!  Boost.Optional helped us manage data 
> > > > collection, but does not help us call trend::loadPoint.  Let's 
> > > > look at
> > > 
> > > The library can just as easily expect a Boost.Optional.
> > 
> > But you're assuming that we have control over the library.  That's 
> > probably the exception rather than the rule in real life.
> 
> If you can change the library to use an adaptor for an 
> optional, why can't you change the library to use the 
> optional directly?
>

But I never gave any indication that we can change the library at all!
Not even to use the adapter.  The adapter is a function object that
returns exactly what the library function expects.

> > > > Using adapters, the call to trend::loadPoint in the 
> first example 
> > > > might look like this:
> > > > 
> > > > 
> > > > // -- begin
> > > > // call trend::loadPoint
> > > > opt_dp::adapter f(-1);
> > > > for( data_set::iterator p = d.begin(); p != d.end(); ++p ) {
> > > >     tr.loadPoint( f(*p) );
> > > > }
> > > > // -- end
> > > 
> > > Your version, with Boost.Optional was like this:
> > > 
> > > >    for( data_set::iterator p = d.begin(); p != d.end(); ++p ) {
> > > >        tr.loadPoint( *p ? p->get() : -1 );
> > > >    }
> > > 
> > > (I think you could change "p->get()" to "**p" if you like, BTW.)
> > > 
> > > The latter is simpler and seems far more direct and, therefore, 
> > > readable.  I don't see that your adapter has added any value.
> > 
> > I tried to make the examples as syntactically plain as 
> possile; they 
> > are optimized for clarity.  There is a key advantage in the example 
> > with adapters because the adapter is a function object.  In that 
> > respect, the door has been flung open to many templated constructs 
> > that are more difficlt with the ?: operator.  For example, a 
> > boost::transform_iterator could be created with the adapter to 
> > automatically access the underlying objects in a sequence.
> 
> Hmmm.  This reminds me of using the STL algorithms before 
> having Boost.Lambda, Boost.Bind, etc.  Without a library of 
> predefined function objects that perform useful, reusable 
> adaptations, or a lambda approach to creating the adapters, 
> one winds up separating the value extraction logic from the 
> context in which it is used.
>

The Boost.Optional::adapter syntax is its own predefined library and,
though lambda is a fantastic approach, it won't compile using Microsoft
so we can't say it's the new paradigm.

> > > I don't really see the value as presented thus far.  
> There is a tiny 
> > > amount of syntactic sugar, but is that warranted?
> > 
> > I'm not sure.
> 
> It was your idea, and now you're questioning it?  I take from 
> that the responses you've gotten have caused you to rethink 
> not just the approach, but the idea?
>

Not at all.  I would distrust anyone who has total faith in the
usefulness of a new idea such as this one.  The need for another opinion
is why forums such as this one even exist.

> > > Your requirements are flawed.  The adapter should hold an 
> instance 
> > > of type T as provided by the constructor.  Then, if the 
> > > Boost.Optional has no value, the adapter can return it's default 
> > > instance.  IOW, the adapter shouldn't impose its needs on the 
> > > optional type.  Boost.Optional would then work fine, 
> though I still 
> > > question the value of your adapter.
> > 
> > I would also like to see the adapter avoid "imposing its 
> needs" on the 
> > optional object, but conversely, I don't think it would be 
> right to to 
> > return whole T objects (instead of references).
> 
> There's no need.  As I pointed out, the adapter can hold its 
> own T instance which represents the default.  Then, when 
> asked for a value (returned by reference), the adapter 
> queries the optional.
> If the optional has a value, the adapter returns the 
> optional's value.  If not, the adapter returns the default 
> value it holds.
>

I considered that approach.  It could be used to return only const
references, which may or may not be enough.

-Andy