May 17, 2003
> It might be a good idea to do an "op" prefix to all the operator
overloads.

I agree.. though I wonder, is operator-overloading meant to be
implementation-specific?  If so, no problem.  If not, then might it be
better to have a slightly more explicit system for overloading?  I.e., an
overloading keyword such as C++'s
    Class Class::operator+(Class obj) {
        ...
    }

In D we could perhaps use something like
    Class operator add(Class obj) { //overload +
        ...
    }


May 17, 2003
Walter wrote:
> It might be a good idea to do an "op" prefix to all the operator overloads.

As you mention that... maybe.

How about another prefix ("oprev"?), which would allow to reverse parameter order for infix operators? Then an operator resolver would have to look both in the "left" class (for "op...") as in the "right" one (for "oprev..."), and complain if there's a collision.

The motivation for this would be the ability to add new "mathematic" classes to the hierarchy without having to resort to module-wide operator definitions, which are usually done in C++.

-i.

May 18, 2003
Personally, I think that operator overloading should be something like in
C++.
why?? because it is nicer, easy to remember, and people reading the code
would know that it is actually an operator.

another thing, there is no way to create operators outside the class, like
you
do for the istream or ostream objects in c++.

giancarlo

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:ba5kre$e25$1@digitaldaemon.com...
> Walter wrote:
> > It might be a good idea to do an "op" prefix to all the operator
overloads.
>
> As you mention that... maybe.
>
> How about another prefix ("oprev"?), which would allow to reverse
> parameter order for infix operators? Then an operator resolver would
> have to look both in the "left" class (for "op...") as in the "right"
> one (for "oprev..."), and complain if there's a collision.
>
> The motivation for this would be the ability to add new "mathematic" classes to the hierarchy without having to resort to module-wide operator definitions, which are usually done in C++.
>
> -i.
>


May 18, 2003
I agree.  I like C++ operator overloading better.  It bugs me that if I want a '+' I have to type 'add';  I really cannot see the problem with a WYSIWYG system.  It's not that much more work in the parser, is it?

The inability to make free operators is really limiting.  It means you can't make operator overloads unless you have full control to the source of at least one of the classes involved, but in many cases you may not own either of the classes but may still want to provide an overloaded operator for some reason. (What if someone invents a cool STL trick that works like that, in the future...?  C++ will be able to do it, D won't.)  There doesn't seem to be any real reason why not, except that this way allows operators to be virtual, which I say is hogwash since you could always define your operator to call a virtual method of the class itself if you choose to.

Sean

"Giancarlo Bellido" <vicentico1@hotmail.com> wrote in message news:ba6l78$1gro$1@digitaldaemon.com...
> Personally, I think that operator overloading should be something like in
> C++.
> why?? because it is nicer, easy to remember, and people reading the code
> would know that it is actually an operator.
>
> another thing, there is no way to create operators outside the class, like
> you
> do for the istream or ostream objects in c++.
>
> giancarlo
>
> "Ilya Minkov" <midiclub@8ung.at> wrote in message news:ba5kre$e25$1@digitaldaemon.com...
> > Walter wrote:
> > > It might be a good idea to do an "op" prefix to all the operator
> overloads.
> >
> > As you mention that... maybe.
> >
> > How about another prefix ("oprev"?), which would allow to reverse
> > parameter order for infix operators? Then an operator resolver would
> > have to look both in the "left" class (for "op...") as in the "right"
> > one (for "oprev..."), and complain if there's a collision.
> >
> > The motivation for this would be the ability to add new "mathematic" classes to the hierarchy without having to resort to module-wide operator definitions, which are usually done in C++.
> >
> > -i.


May 18, 2003
Sean L. Palmer wrote:
> I agree.  I like C++ operator overloading better.  It bugs me that if I want
> a '+' I have to type 'add';  I really cannot see the problem with a WYSIWYG
> system.  It's not that much more work in the parser, is it?

It shall make writing other tools which process D code more difficult. Not the EOW though. But i frankly don't know why add bothers you. You can grep after it. You know where to search for an operator definition for a reference. Unlike freestanding operator defintions, which can be anywhere.

> The inability to make free operators is really limiting.  It means you can't
> make operator overloads unless you have full control to the source of at
> least one of the classes involved, but in many cases you may not own either
> of the classes but may still want to provide an overloaded operator for some
> reason.

What the h*** that reason would be? Bad original library design?

Besides: you don't have to be in control of source to add operators to existing classes. Simply subclass. There also is a technique which allows you to do that to structs.

> (What if someone invents a cool STL trick that works like that, in
> the future...?  C++ will be able to do it, D won't.)  There doesn't seem to
> be any real reason why not, except that this way allows operators to be
> virtual, which I say is hogwash since you could always define your operator
> to call a virtual method of the class itself if you choose to.

Operators *have* to be virtual, else you would be redefining them to call virtual methods for each of descendants of some basic mathematic class.

Think OO people. I feel like changing to Sather.

-i.

May 18, 2003
ok, what about declaring the operator like a function without the operator
keyword,
like:

    classname + (classname2 r);

and about free operators i think they are important because they give more
control
over types, because there is no way to add functionality to a class like the
istream,
ostream class in c++, the only way by now is modifying the source.

giancarlo

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:ba8954$je6$1@digitaldaemon.com...
> Sean L. Palmer wrote:
> > I agree.  I like C++ operator overloading better.  It bugs me that if I
want
> > a '+' I have to type 'add';  I really cannot see the problem with a
WYSIWYG
> > system.  It's not that much more work in the parser, is it?
>
> It shall make writing other tools which process D code more difficult. Not the EOW though. But i frankly don't know why add bothers you. You can grep after it. You know where to search for an operator definition for a reference. Unlike freestanding operator defintions, which can be anywhere.
>
> > The inability to make free operators is really limiting.  It means you
can't
> > make operator overloads unless you have full control to the source of at least one of the classes involved, but in many cases you may not own
either
> > of the classes but may still want to provide an overloaded operator for
some
> > reason.
>
> What the h*** that reason would be? Bad original library design?
>
> Besides: you don't have to be in control of source to add operators to existing classes. Simply subclass. There also is a technique which allows you to do that to structs.
>
> > (What if someone invents a cool STL trick that works like that, in
> > the future...?  C++ will be able to do it, D won't.)  There doesn't seem
to
> > be any real reason why not, except that this way allows operators to be virtual, which I say is hogwash since you could always define your
operator
> > to call a virtual method of the class itself if you choose to.
>
> Operators *have* to be virtual, else you would be redefining them to call virtual methods for each of descendants of some basic mathematic
class.
>
> Think OO people. I feel like changing to Sather.
>
> -i.
>


May 18, 2003
Giancarlo Bellido wrote:
> ok, what about declaring the operator like a function without the
> operator keyword, like:
> 
> classname + (classname2 r);

Yikes, UGLY! The problem with it is that you cannot grep for it. In C++ you would search for "operator" or "operator+", in Walter's proposal you can search for "op" or "opadd", but yours is simply painful.

> and about free operators i think they are important because they give
> more control over types, because there is no way to add functionality
> to a class like the istream, ostream class in c++, the only way by
> now is modifying the source.

Consider: do you really need to add functioality to these classes? If you feel like adding more classes to the iostream hierarchy, "reverse" operator definitions would allow that. If you think SomeLibraryClass is not advanced enough... go ahead and subclass it into MySomeLibraryClass. Then you would be able not only to add operators, but also add new methods or modify existing ones, in a consistent manner. Adding operators just to circumvent this is a mere obfuscation.

-i.

May 18, 2003
Giancarlo Bellido wrote:
> ok, what about declaring the operator like a function without the operator
> keyword,
> like:
> 
>     classname + (classname2 r);
> 
> and about free operators i think they are important because they give more
> control
> over types, because there is no way to add functionality to a class like the
> istream,
> ostream class in c++, the only way by now is modifying the source.
> 
> giancarlo
> 

Except for shl_r and shr_r :)

class MyClass
{
   Stream shl_r(Stream s)
   {
      doStuffWith(s);
      return s;
   }
}

May 19, 2003
I didn't like the "operator+" notation because of the problem with the reverse operators.

"C. Sauls" <ibisbasenji@yahoo.com> wrote in message news:ba5jnn$d47$1@digitaldaemon.com...
> > It might be a good idea to do an "op" prefix to all the operator
> overloads.
>
> I agree.. though I wonder, is operator-overloading meant to be
> implementation-specific?  If so, no problem.  If not, then might it be
> better to have a slightly more explicit system for overloading?  I.e., an
> overloading keyword such as C++'s
>     Class Class::operator+(Class obj) {
>         ...
>     }
>
> In D we could perhaps use something like
>     Class operator add(Class obj) { //overload +
>         ...
>     }
>
>


May 19, 2003
"Ilya Minkov" <midiclub@8ung.at> wrote in message news:ba8954$je6$1@digitaldaemon.com...
> It shall make writing other tools which process D code more difficult. Not the EOW though. But i frankly don't know why add bothers you. You can grep after it. You know where to search for an operator definition for a reference. Unlike freestanding operator defintions, which can be anywhere.

To me, being able to grep for it is a big deal. I also know where to look for the operator overloads for a particular class. I don't with global operator overloads.

It's like overloading the global ::new in C++. It seemed like a good idea at first, but after a while I excorcised all of that from my code and switched to local operator new's.