« Return to Thread: Updated version of futures library
Re: Updated version of futures library
by Frank Mori Hess-2
::
Rate this Message:
On Sunday 01 June 2008 06:34, Felipe Magno de Almeida wrote:
> >> 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.
>
> I tend to agree with Frank's view of overloading && and || for futures.
> I'm surely not a never-overload-operators-guy. I, for instance, love
> spirit. But in spirit && and || has a specific meaning inside EBNF
> domain. In futures, we're just inventing that meaning.
> Couldn't lambda's help us more than overloading here?Oh, I came up with another reason. A future can be empty (default
constructed, or a moved unique_future). Such classes often support
converson to bool (or conversion to "unspecified boolean type" when they
want to be safer) to test if they have been initialized. So seeing a
future in a logical operator, one might mistakenly assume the operator is
is a test to see if either or both futures have been initialized.
Although, to nit-pick myself, I don't think the statement I made about the
logical operators already being overloaded was technically correct. I
suppose its really the conversion-to-bool operator that is overloaded and
there is just the bool prototype for the logical operators.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> >> 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.
>
> I tend to agree with Frank's view of overloading && and || for futures.
> I'm surely not a never-overload-operators-guy. I, for instance, love
> spirit. But in spirit && and || has a specific meaning inside EBNF
> domain. In futures, we're just inventing that meaning.
> Couldn't lambda's help us more than overloading here?
constructed, or a moved unique_future). Such classes often support
converson to bool (or conversion to "unspecified boolean type" when they
want to be safer) to test if they have been initialized. So seeing a
future in a logical operator, one might mistakenly assume the operator is
is a test to see if either or both futures have been initialized.
Although, to nit-pick myself, I don't think the statement I made about the
logical operators already being overloaded was technically correct. I
suppose its really the conversion-to-bool operator that is overloaded and
there is just the bool prototype for the logical operators.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
attachment0 (196 bytes) « Return to Thread: Updated version of futures library
| Free embeddable forum powered by Nabble | Forum Help |
