Re: [boost] [futures] boost::futures - operator&& operator||

From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2007-03-16 08:51:43

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 16 March 2007 03:23 am, Oliver.Kowalke_at_[hidden] wrote:
> I still believe that futures should be combinable via operator&& and
> operator|| - for users of the boost::future library is it more intuitive
> that the resulting future of an future comination contains the result
> instead of future<bool> and be force to check all related futures for
> their return status and return value.

I've clearly failed to communicate my criticisms clearly.  I was not 
presenting an alternate syntax for the future combination functions.  I 
was presenting another function with semantics that bear no direct 
relation to the combination functions, but whose prototype would conflict 
with the proposed use of operator|| and && for the combination functions. 

Maybe it would have been clearer if I had said

future<bool> operator||(const future<bool> &, const future<bool>&);

I was not objecting to the functionality of combining futures (I don't 
really have an opinion on that) I was objecting to the choice of 
overloading operators instead of using normal function names.

To a user of libpoet, where the correspondence between futures and their 
values is emphasized, seeing something like

future_a || future_b

in code, the principle of least surprise would  lead them to guess that the 
meaning of the overloaded operation would be to return a future whose 
value corresponded to applying logical or to the values of future_a and 
future_b.  This behaviour would correspond to an active_function created 
from the ordinary operator|| acting on values.

The confusion only underscores my point.  Overloading a function name (or 
operator) with multiple functions that bear no direct semantic 
relationship to each other is merely confusing.  The namespace for 
possible operators is extremely limited.  Unfortunately, this seems to 
make everyone with a neat idea want to overload an operator with it, so 
that everyone notices their function and is more likely to use it.

- -- 
Frank
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFF+pLk5vihyNWuA4URAsFfAKC40HgefbbOcYUvuPItqIxO4+6jEgCg4uMW
dwoS6I+e1t3oWN8gbnCmDCk=
=9llc
-----END PGP SIGNATURE-----