Re: [boost] New Library Proposal: dual_state

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-07-15 12:57:46

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 Rob Stewart
> > > > From: "Jost, Andrew" <Andrew_Jost_at_[hidden]>
> > > > > > From: boost-bounces_at_[hidden] 
> > > > > > [mailto:boost-bounces_at_[hidden]] On Behalf Of Fernando 
> > > > > > Cacciola
> > > > > 
> > > > 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.

Huh?  Your first example showed code using Boost.Optional and the
conditional operator.  Then you changed it to use an adapter.

What unchangeable library code can use an adapter that couldn't
have used Boost.Optional in the first place?  That is, the
library code would have been written to take a value initially.
To account for the optional/default behavior, the library must
change to take an adapter or a boost::optional.

Since your adapter doesn't have value semantics, but rather
function call semantics, a library written to expect a value
cannot work *without change* with an adapter.

What have I missed?

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

Huh?

What is "Boost.Optional::adapter syntax?"

By "Microsoft," I assume you mean MSVC.  Since BLL was only one
of the libraries I mentioned, I have to ask: what's your point?

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

If you're unsure of the idea, though, we can't move forward.

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

Are you considering the possibility that the value returned by
the adapter could be a reference to non-const?  I wasn't thinking
of that at all.  I saw it purely as getting a value.  In fact, I
thought your use case was simply that the value needed might not
be available, so a substitute can be provided.  Indeed, returning
a non-const reference to T would mean that one should use a copy
of the original optional because one might need different
defaults for different uses of that optional.

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