From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2007-03-16 08:51:43
-----BEGIN PGP SIGNED MESSAGE-----
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
-----END PGP SIGNATURE-----
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk