Re: [boost] New Library Proposal: dual_state

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-07-15 13:01:51

From: Andrey Melnikov <melnikov_at_[hidden]>
> Rob Stewart wrote:
> > From: "Jost, Andrew" <Andrew_Jost_at_[hidden]>
> > 
> >>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?
> 
> Adapters work outside the library and don't require any changes to the 
> library. Library requires underlying values, and with the adapter it 
> gets them automagically. The library doesn't know anything about 
> Optional and adapters, library clients do.

Any function that expects a value can be given either a default
or the value in an optional just as easily as an the value from
an adapter.

However, if the library code retrieves the value itself--which is
what I meant by the need to change the library code--then it must
know that the type is now an adapter or optional.

> >>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.
> 
> Do you mean that efforts to create a custom function object aren't worth 
> of the result, and most people will just end with using IFs and refusing 
> to create an adapter or a function object for an existing adapter?

Yes.

> So far I think we can live with just Optional and 
> OptionalWithDefaultValue. A default value is needed very often.

I'm not sure about OptionalWithDefaultValue.  It depends upon how
it works and what it imposes on its parameterizing type.

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