Re: [boost] New Library Proposal: dual_state

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-07-14 08:52:55

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?

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

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

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

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.

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

Don't quote things like that.  Some like to quote a person's name
and put their own immediately after -- for reasons I don't
understand -- but there's no need for all of this text.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;