Re: [boost] New Library Proposal: dual_state

From: Jost, Andrew (Andrew_Jost_at_[hidden])
Date: 2005-07-14 07:26:58

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Rob Stewart
> Sent: Thursday, July 14, 2005 3:34 AM
> 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 Fernando 
> > > Cacciola
> > 
> > Here is a real example.  Imagine a researcher with many instruments
> [snip long example indicating that using Boost.Optional for 
> data collection works fine, but for using or reporting that 
> information, Boost.Optional falls short]
> > 
> > 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 
> another example.
> 
> 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.

<clip>

> > translation point is where I see the need for guaranteed object 
> > delivery, for it seems that Boost.Optional and guaranteed object 
> > delivery are two ends of the same pipeline: at the head, we 
> obtain (or 
> > fail to obtain) a value, and in the process escape the need for a 
> > signal value; at the tail, we use the values we've 
> obtained, possibly 
> > in a context that EXPECTS signal values.  Requires them.  
> So far we've 
> > used only the trinary operator to perform this translation, but is 
> > there a better way?
> 
> The fundamental issue seems to be that you want an object or 
> function that automagically produces a value, even if one 
> wasn't otherwise available.

Yes.

<clip>

> > 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.

<snip>
> 
> 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.

> > But, why do I keep saying optional instead of 
> Boost.Optional?  To see, 
> > we must think about how an adapter interacts with the 
> optional object 
> > on which it operates.  I won't spell out the fairly obvious 
> point that 
> > adapters should return references rather than whole T 
> objects, but if 
> > this is so, then an adapter that operates on an empty 
> optional object 
> > must ask that optional to, first, construct a new T object, then 
> > return a reference to that new object.  Based on this, we can say a 
> > few things about an optional object, X, on which an adapter 
> operates:
> > 
> > 	(a) X must have valid EMPTY and FULL states.
> > 	(b) There must exist for X a valid EMPTY state, S, in which X 
> > privately holds an object, x, of type T.
> > 	(c) If X is EMPTY (including state S), then altering or 
> replacing the 
> > internal x without setting the state to FULL is a "const this" 
> > operation.
> 
> 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).

> 
> -- 
> Rob Stewart                           stewart_at_[hidden]
> Software Engineer                     http://www.sig.com
> Susquehanna International Group, LLP  using std::disclaimer; 
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>