Re: Updated version of futures library

On Saturday 31 May 2008 21:19, Hartmut Kaiser wrote: Ah, I think I'm understanding you better now.  You are appalled by the idea
of treating a future<T> like it was a T, is that correct?  You want a
future<T> to only be treated like an abstract handle to a value, not the
value itself?  I wasn't ignoring your point, it's just that your view is
extremely foreign to how I view futures, so your words were almost
meaningless to me.  I view being able to view a future<T> as a placeholder
for a T object as a large part of what makes futures useful.  I
implemented the future class in libpoet to support that, with implicit
conversions from future<T> to future<U>, from T to future<T>, etc.  And
being able to treat a future<T> as a placeholder for a T is essential to
implementing things like poet::active_function.  

I don't particularly like the implicit conversion from T to future<T>, but
that has absolutely nothing to do with not wanting to treat a future<T> as
a placeholder.  It's simply because the conversion can block, and thus
produce unexpected behavior (an object appearing on the right hand side of
an assignment stalling your program).  The explicit future::get() at least
gives a hint that something more than a quick conversion might be
happening.

I guess the features that allow a future to act as a placeholder could be
split out into a separate higher level class, call it "future_value",
which would internally contain a plain old future.  The idea doesn't
really do anything for me, but maybe you would find it preferable?

> OTOH, IMHO, having the logical operators alone improves code
> readability, simplifies the implementation (by avoiding multiple
> overloads for different parameter counts), allows to build more complex
> logical execution restrictions as (f1 || f2) && f3 (which is not
> possible using the proposed wait_for_all and wait_for_any), and all that
> without having to sacrifice any of the existing functionality.

The
poet::future_barrier/future_composing_barrier/future_select/future_selector
stuff I'm currently working on allows for composition.  Did you see the
earlier discussion on this a couple weeks ago?  For example this thread:

http://lists.boost.org/Archives/boost/2008/05/137417.php

>
> > Personally, I don't particularly want to see a future
> > library overload any logical operators at all, or at least have the
> > overloads sequestered in separate headers that aren't included by any
> > of the other future library headers.
>
> That's a matter of taste, for sure. But would you mind telling us why
> you don't want to have these? Your opinion sounds to be quite strong, so
> you must have good reasons!

It's the obvious reason.  I don't think taking a function with a 2 letter
name, which is already overloaded, and adding a new set of overloads to it
which have semantics completely unrelated to the existing overloads is a
desirable or aesthetically pleasing interface.  No one would even consider
doing such a thing if the function wasn't an operator.  I guess I just
don't find operator syntax as compelling a feature as others.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost