"Walter" <walter@digitalmars.com> wrote in message news:bb46ij$2nd9$1@digitaldaemon.com...
>
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:ba9vfv$e61$1@digitaldaemon.com...
> > "Walter" <walter@digitalmars.com> wrote in message news:ba9i5m$2l4g$2@digitaldaemon.com...
> > > "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:ba7jsb$2kdn$1@digitaldaemon.com...
> > > > 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 problem comes with the reverse operators, such as divr.
> > What problem?
> > float operator-(int a, float b) { return float(a) - b; }
> > float operator-(float a, int b) { return a - float(b); }
>
> That doesn't work if you want to make them virtual.

What if I don't care if they're virtual?  Besides as has been pointed out you can still chain to a virtual member function if you want that.

> > > 3) you need to write, in general, twice as much code in C++ to define
a
> > new
> > > class with operators than you do in D.
> > Example?
>
> In C++, you have to overload both == and !=. In D, one overload handles both. The same for commutative operators - in D, just do one of them, in C++, you must do both. Things are even more wordy in C++ if you want to do <, <=, >, >=. You frequently have to write 8 functions in C++, in D just one.

What does this have to do with the operator being a member function or not? In fact what does it have to do with the naming scheme?  You could easily make default operators in C++;  Boost even does it within the existing language.

I don't understand the current stance on prohibition of nonmember operators. I don't see any good reasoning for it.  But there are good reasons why people want loose operators.  Often the operation doesn't really "belong" in either class.

Look at Java.  They made it so every function has to be a class member.  Now people have to make classes they don't need.

At least let us inherit from basic types:

struct posint : public int
{
}

Sean

>
>I don't understand the current stance on prohibition of nonmember operators. I don't see any good reasoning for it.  But there are good reasons why people want loose operators.  Often the operation doesn't really "belong" in either class.
>
>Look at Java.  They made it so every function has to be a class member.  Now people have to make classes they don't need.

I agree, fake classes to "encapsulate" all functions like Java is bad.

Read
http://www.cuj.com/documents/s=8042/cuj0002meyers/
for a related idea

> I don't understand the current stance on prohibition of nonmember
operators.
> I don't see any good reasoning for it.

Agreed.

> But there are good reasons why
> people want loose operators.  Often the operation doesn't really "belong"
in
> either class.

Agreed.

> Look at Java.  They made it so every function has to be a class member.
Now
> people have to make classes they don't need.

Agreed.

So, in summary, agreed!

It seems like it would be a good idea to unify all function and method call syntax.

But how?  Go back to C?  Occasionally it's kind of nice to know which parameter is the "main" parameter (called this in C++). Several languages do this, but I'm not sure how it works out because I haven't tried it recently. This is how everything worked in C.

Maybe access control, in general, is bad.  Perhaps data and function hiding should be done by some other mechanism, such as modules and scopes and namespaces, and not so much by inheritance.

This is a fundamental issue, one that would drastically alter a language design.

Sean

"Mark T" <Mark_member@pathlink.com> wrote in message news:bb6817$20dc$1@digitaldaemon.com...
> >
> >I don't understand the current stance on prohibition of nonmember
operators.
> >I don't see any good reasoning for it.  But there are good reasons why people want loose operators.  Often the operation doesn't really "belong"
in
> >either class.
> >
> >Look at Java.  They made it so every function has to be a class member.
Now
> >people have to make classes they don't need.
>
> I agree, fake classes to "encapsulate" all functions like Java is bad.
>
> Read
> http://www.cuj.com/documents/s=8042/cuj0002meyers/
> for a related idea

"Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3E87DEA7.A5ABC430@chello.at...
> (3) Any crash is bad. If there is a sensible way to continue operation in
>     a situation we should take the chance to tolerate it. A "close" on a
file
>     that is not open - fine, lets go on. A free on some pointer that is
NULL
>     - whats the problem? An object that doesn't exist compared to null in
D -
>     well sure it should return "true". Nothing else would make more sense.

Crashes, sure. But what is happening here is an exception is thrown, not necessarilly a crash. A null pointer reference throws an exception, which can be caught like any other exception.

The philosophy in D is that errors should be reported by throwing exceptions, not by returning error codes.

If there was any error in my program logic, I'd much rather have an exception promptly thrown. That gives me the best opportunity to debug it, or if I want something else to happen, I can catch that exception and soldier on.

(I view a crash as more like the program corrupted its own data or the operating system's. In MSDOS, a crash usually meant scrambling the entire system. Hardware generated exceptions were a huge advance.)

So, think of (o==p) with objects as "Compare the contents of object o with object p. If either is null, there are no contents, and that is outside the scope of the == operator's purpose. Therefore, an exception is thrown just as if an array bounds were exceeded. If the object references are not supposed to be null, then it's a program bug. If the object references can be null, then explicitly code what a null reference means."