View mode: basic / threaded / horizontal-split · Log in · Help
May 17, 2003
Re: null == o?
> 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
Re: null == o?
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
Re: null == o?
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
Re: null == o?
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
Re: null == o?
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
Re: null == o?
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
Re: null == o?
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
Re: null == o?
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
Re: null == o?
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
Re: null == o?
"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.
3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home