www.digitalmars.com         C & C++   DMDScript  

D - Free Operator Function Overloads

reply davepermen <davepermen_member pathlink.com> writes:
Walter

this is essencial. not only for streaming libraries, but simply in general.. an

Tc = Ta + Tb doesn't have ANY preference for any of those 3 types. it should be

Tc opAdd(Ta a,Tb b) {}

and not

Tc Ta.opAdd(Tb b) {}

or

Tc Tb.opAddR(Ta a) {}

or even worse, both!

just get rid of it. binary operators don't belong to a member. they never did.

and if you release that essencial missconcept, and replace it by the only real
one, we gain immediate access to a very fast implementable typesave, and
extendable streaming library..

Tc operator add(Ta a,Tb b) { }

would be my prefered way.
Jan 05 2004
next sibling parent reply Felix <Felix_member pathlink.com> writes:
Me too, I find a little weird the syntax Ta.opAdd(Tb) but, if I remember, this
is the standard way to overload operators in C++, too. Maybe, if cannot be
simply dropped, an alternative definition will be suitable.



In article <btbq8o$2g9e$1 digitaldaemon.com>, davepermen says...
Walter

this is essencial. not only for streaming libraries, but simply in general.. an

Tc = Ta + Tb doesn't have ANY preference for any of those 3 types. it should be

Tc opAdd(Ta a,Tb b) {}

and not

Tc Ta.opAdd(Tb b) {}

or

Tc Tb.opAddR(Ta a) {}

or even worse, both!

just get rid of it. binary operators don't belong to a member. they never did.

and if you release that essencial missconcept, and replace it by the only real
one, we gain immediate access to a very fast implementable typesave, and
extendable streaming library..

Tc operator add(Ta a,Tb b) { }

would be my prefered way.
Jan 05 2004
parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <btbv9t$2p2s$1 digitaldaemon.com>, Felix wrote:
 Me too, I find a little weird the syntax Ta.opAdd(Tb) but, if I remember, this
 is the standard way to overload operators in C++, too. Maybe, if cannot be
 simply dropped, an alternative definition will be suitable.
There's no "standard" way in C++, you can pick any way you like. The things that affect your choice are the same with operators and other functions: - only member functions/operators can be overridden in a derived class - only non-member functions can be used to extend the class after it has been closed For example, suppose that the standard output mechanism in D would be something like Printer stdout; void main() { stdout ~ "Hello world " ~ 1 ~ 2 ~ 3 ~ endl; } And Printer implemented something like: class Printer { Printer opCat(int i) { .. } Printer opCat(char[] c) { .. } Printer opCat(Object o) { .. } } [replace Printer with OutputStream if you feel very generic] then the only way to introduce a new printable user-defined type, say Vector3, that isn't derived from Object but still can be printed to stdout is to make a free-standing function: Printer opCat(Printer p, Vector3 v) { p ~ "(" ~ v.x ~ ", " ~ v.y ~ ", " ~ v.z ~ ")"; } That is, if that was possible in D. You can do that in C++. If D was an OO only language, then making types not derived from Object would not be possible and the issue would be moot. Heck, we could be as well programming in Java. But I gather D is supposed be multiparadigm and all that, and you ought to be able to do stuff also without objects if you want. I object to objects. And if there is some template code somewhere, saying "stdout ~ t" where t is of type which is argument for the template, you sure as hell want your Vector3 to be printed instead of getting a message along the lines of "Printer does not have member function opCat(Printer, Vector3). Wanna change it? You can't! Bwahaha!". Duh! So to conclude the rant, I fully agree with davepermen:
 just get rid of it. binary operators don't belong to a member. they
 never did.
and Matthew:
 That's something we need that is supported by a large number of
 issues, not just this one. It's an absolute must, and I can't seee
 Walter escaping us on this one. :)
The only potential problems I see with free-standing operators are: 1. Importing or not importing a module containing operators will affect the way functions are overloaded. "a + b" might mean a different thing after adding an import. On the other hand, normal function calls are already vulnerable for this and I haven't experienced any problems whatsoever. Nor have I had any problems with the issue in C++, where it also exists. 2. The overloading rules might be a tad more complex with freestanding operators. That is, they might require some thinking so that they don't cause any surprises. Maybe there is someone less tired to perform the thinking ;) Complexity doesn't bother me if the rules are sufficiently simple to grasp intuitively. (Unless they end up in some Snake-Tongued Two-Phased Koenig Lookup or similar maze of mirrors) If there are any other valid reasons against non-member operators, please bring them forth because I for one have forgotten them. Did the original D "vision" include them? Why/why not? Is the reason that they haven't been implemented a reason of principle or merely a practical one? By tackling those issues one by one we might even arrive at a solution that satisfies everyone. At least, one can hope... -Antti
Jan 05 2004
next sibling parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
I agree it would probably be better to have binary overloading decoupled
from methods (trading off run-time dispatching against extending classes
without subclassing). But... from the D doc:
 "In D, function overloading is simple. It matches exactly, it matches with
implicit conversions, or it does not match. If there is more than one match,
it is an error."

So does that mean I can't specialize an existing function like:
Number opAdd(Number, int) {...}
NumberSubclass opAdd(NumberSubclass,int) {...}

If I have a variable of type NumberSubclass and I write "x+1" then it could
match both (one exactly and the other with an implicit conversion) and so
that would be an error. Or what if I had a subclass of NumberSubclass (so
there would be two implicit conversion matches).
It seems to me that this would make the proposed behavior of binary operator
overloading less useful. Not unusable, I suppose. It would worth looking at
a bunch of examples to see what would actually happen with either design and
what the advantages and disadvantages of each would be. I for one can't
immediately tell why one or the other would be a "no-brainer".

-Ben

"Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
news:slrnbvjcbm.69b.jsykari pulu.hut.fi...
 In article <btbv9t$2p2s$1 digitaldaemon.com>, Felix wrote:
 Me too, I find a little weird the syntax Ta.opAdd(Tb) but, if I
remember, this
 is the standard way to overload operators in C++, too. Maybe, if cannot
be
 simply dropped, an alternative definition will be suitable.
There's no "standard" way in C++, you can pick any way you like. The things that affect your choice are the same with operators and other functions: - only member functions/operators can be overridden in a derived class - only non-member functions can be used to extend the class after it has been closed For example, suppose that the standard output mechanism in D would be something like Printer stdout; void main() { stdout ~ "Hello world " ~ 1 ~ 2 ~ 3 ~ endl; } And Printer implemented something like: class Printer { Printer opCat(int i) { .. } Printer opCat(char[] c) { .. } Printer opCat(Object o) { .. } } [replace Printer with OutputStream if you feel very generic] then the only way to introduce a new printable user-defined type, say Vector3, that isn't derived from Object but still can be printed to stdout is to make a free-standing function: Printer opCat(Printer p, Vector3 v) { p ~ "(" ~ v.x ~ ", " ~ v.y ~ ", " ~ v.z ~ ")"; } That is, if that was possible in D. You can do that in C++. If D was an OO only language, then making types not derived from Object would not be possible and the issue would be moot. Heck, we could be as well programming in Java. But I gather D is supposed be multiparadigm and all that, and you ought to be able to do stuff also without objects if you want. I object to objects. And if there is some template code somewhere, saying "stdout ~ t" where t is of type which is argument for the template, you sure as hell want your Vector3 to be printed instead of getting a message along the lines of "Printer does not have member function opCat(Printer, Vector3). Wanna change it? You can't! Bwahaha!". Duh! So to conclude the rant, I fully agree with davepermen:
 just get rid of it. binary operators don't belong to a member. they
 never did.
and Matthew:
 That's something we need that is supported by a large number of
 issues, not just this one. It's an absolute must, and I can't seee
 Walter escaping us on this one. :)
The only potential problems I see with free-standing operators are: 1. Importing or not importing a module containing operators will affect the way functions are overloaded. "a + b" might mean a different thing after adding an import. On the other hand, normal function calls are already vulnerable for this and I haven't experienced any problems whatsoever. Nor have I had any problems with the issue in C++, where it also exists. 2. The overloading rules might be a tad more complex with freestanding operators. That is, they might require some thinking so that they don't cause any surprises. Maybe there is someone less tired to perform the thinking ;) Complexity doesn't bother me if the rules are sufficiently simple to grasp intuitively. (Unless they end up in some Snake-Tongued Two-Phased Koenig Lookup or similar maze of mirrors) If there are any other valid reasons against non-member operators, please bring them forth because I for one have forgotten them. Did the original D "vision" include them? Why/why not? Is the reason that they haven't been implemented a reason of principle or merely a practical one? By tackling those issues one by one we might even arrive at a solution that satisfies everyone. At least, one can hope... -Antti
Jan 05 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:btd7ks$1li5$1 digitaldaemon.com...
 I agree it would probably be better to have binary overloading decoupled
 from methods (trading off run-time dispatching against extending classes
 without subclassing). But... from the D doc:
  "In D, function overloading is simple. It matches exactly, it matches
with
 implicit conversions, or it does not match. If there is more than one
match,
 it is an error."

 So does that mean I can't specialize an existing function like:
 Number opAdd(Number, int) {...}
 NumberSubclass opAdd(NumberSubclass,int) {...}

 If I have a variable of type NumberSubclass and I write "x+1" then it
could
 match both (one exactly and the other with an implicit conversion) and so
 that would be an error. Or what if I had a subclass of NumberSubclass (so
 there would be two implicit conversion matches).
I sincerely hope that the compiler could umabiguously match the second operator. If not, we're storing up a heap of trouble for later. Walter, can you clarify what will happen here?
 It seems to me that this would make the proposed behavior of binary
operator
 overloading less useful. Not unusable, I suppose. It would worth looking
at
 a bunch of examples to see what would actually happen with either design
and
 what the advantages and disadvantages of each would be. I for one can't
 immediately tell why one or the other would be a "no-brainer".

 -Ben

 "Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
 news:slrnbvjcbm.69b.jsykari pulu.hut.fi...
 In article <btbv9t$2p2s$1 digitaldaemon.com>, Felix wrote:
 Me too, I find a little weird the syntax Ta.opAdd(Tb) but, if I
remember, this
 is the standard way to overload operators in C++, too. Maybe, if
cannot
 be
 simply dropped, an alternative definition will be suitable.
There's no "standard" way in C++, you can pick any way you like. The things that affect your choice are the same with operators and other functions: - only member functions/operators can be overridden in a derived class - only non-member functions can be used to extend the class after it has been closed For example, suppose that the standard output mechanism in D would be something like Printer stdout; void main() { stdout ~ "Hello world " ~ 1 ~ 2 ~ 3 ~ endl; } And Printer implemented something like: class Printer { Printer opCat(int i) { .. } Printer opCat(char[] c) { .. } Printer opCat(Object o) { .. } } [replace Printer with OutputStream if you feel very generic] then the only way to introduce a new printable user-defined type, say Vector3, that isn't derived from Object but still can be printed to stdout is to make a free-standing function: Printer opCat(Printer p, Vector3 v) { p ~ "(" ~ v.x ~ ", " ~ v.y ~ ", " ~ v.z ~ ")"; } That is, if that was possible in D. You can do that in C++. If D was an OO only language, then making types not derived from Object would not be possible and the issue would be moot. Heck, we could be as well programming in Java. But I gather D is supposed be multiparadigm and all that, and you ought to be able to do stuff also without objects if you want. I object to objects. And if there is some template code somewhere, saying "stdout ~ t" where t is of type which is argument for the template, you sure as hell want your Vector3 to be printed instead of getting a message along the lines of "Printer does not have member function opCat(Printer, Vector3). Wanna change it? You can't! Bwahaha!". Duh! So to conclude the rant, I fully agree with davepermen:
 just get rid of it. binary operators don't belong to a member. they
 never did.
and Matthew:
 That's something we need that is supported by a large number of
 issues, not just this one. It's an absolute must, and I can't seee
 Walter escaping us on this one. :)
The only potential problems I see with free-standing operators are: 1. Importing or not importing a module containing operators will affect the way functions are overloaded. "a + b" might mean a different thing after adding an import. On the other hand, normal function calls are already vulnerable for this and I haven't experienced any problems whatsoever. Nor have I had any problems with the issue in C++, where it also exists. 2. The overloading rules might be a tad more complex with freestanding operators. That is, they might require some thinking so that they don't cause any surprises. Maybe there is someone less tired to perform the thinking ;) Complexity doesn't bother me if the rules are sufficiently simple to grasp intuitively. (Unless they end up in some Snake-Tongued Two-Phased Koenig Lookup or similar maze of mirrors) If there are any other valid reasons against non-member operators, please bring them forth because I for one have forgotten them. Did the original D "vision" include them? Why/why not? Is the reason that they haven't been implemented a reason of principle or merely a practical one? By tackling those issues one by one we might even arrive at a solution that satisfies everyone. At least, one can hope... -Antti
Jan 05 2004
parent "Walter" <walter digitalmars.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:btd95n$1o1a$1 digitaldaemon.com...
 "Ben Hinkle" <bhinkle4 juno.com> wrote in message
 news:btd7ks$1li5$1 digitaldaemon.com...
 I agree it would probably be better to have binary overloading decoupled
 from methods (trading off run-time dispatching against extending classes
 without subclassing). But... from the D doc:
  "In D, function overloading is simple. It matches exactly, it matches
with
 implicit conversions, or it does not match. If there is more than one
match,
 it is an error."

 So does that mean I can't specialize an existing function like:
 Number opAdd(Number, int) {...}
 NumberSubclass opAdd(NumberSubclass,int) {...}

 If I have a variable of type NumberSubclass and I write "x+1" then it
could
 match both (one exactly and the other with an implicit conversion) and
so
 that would be an error. Or what if I had a subclass of NumberSubclass
(so
 there would be two implicit conversion matches).
I sincerely hope that the compiler could umabiguously match the second operator. If not, we're storing up a heap of trouble for later. Walter, can you clarify what will happen here?
It'll match the second, since it is an exact match. The first is a match with conversions.
Jan 06 2004
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
news:slrnbvjcbm.69b.jsykari pulu.hut.fi...
 If there are any other valid reasons against non-member operators,
 please bring them forth because I for one have forgotten them. Did the
 original D "vision" include them? Why/why not? Is the reason that they
 haven't been implemented a reason of principle or merely a practical
 one?
The problem is that if they were implemented, then there'd be a need for Koenig lookup. Once there's Koenig lookup, then there's the export lookup madness.
Jan 05 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Walter" <walter digitalmars.com> wrote in message
news:btda5i$1puo$1 digitaldaemon.com...
 "Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
 news:slrnbvjcbm.69b.jsykari pulu.hut.fi...
 If there are any other valid reasons against non-member operators,
 please bring them forth because I for one have forgotten them. Did the
 original D "vision" include them? Why/why not? Is the reason that they
 haven't been implemented a reason of principle or merely a practical
 one?
The problem is that if they were implemented, then there'd be a need for Koenig lookup.
With you so far
 Once there's Koenig lookup, then there's the export lookup
 madness.
Please explain
Jan 05 2004
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:btdalv$1qml$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:btda5i$1puo$1 digitaldaemon.com...
 "Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
 news:slrnbvjcbm.69b.jsykari pulu.hut.fi...
 If there are any other valid reasons against non-member operators,
 please bring them forth because I for one have forgotten them. Did the
 original D "vision" include them? Why/why not? Is the reason that they
 haven't been implemented a reason of principle or merely a practical
 one?
The problem is that if they were implemented, then there'd be a need for Koenig lookup.
With you so far
 Once there's Koenig lookup, then there's the export lookup
 madness.
Please explain
I've done some extensive googling for info on export. It seems the main difficulty with export is the ADL. The two phase lookup comes in to play, once when the template is defined and the other when it is instantiated. The second lookup is the ADL one. The ADL can cut across all of the 'translation units', meaning an arbitrarilly large number of separate symbol tables need to be analyzed. This is essentially madness. As best as I can tell, this problem was not realized when export was voted into the Standard, and is the source of many opinions that export is unimplementable. EDG proved it could be implemented, reportedly consuming 3 man years, but I don't hear any more about the alleged advantages of export (code hiding, faster compilation), and hence I suspect those advantages do not occur in practice. Export is a canonical example of how backwards compatibility with seemingly innocuous design decisions can lead to disaster. I do not wish to import that madness into D <g>.
Jan 06 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:btdalv$1qml$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:btda5i$1puo$1 digitaldaemon.com...
 "Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
 news:slrnbvjcbm.69b.jsykari pulu.hut.fi...
 If there are any other valid reasons against non-member operators,
 please bring them forth because I for one have forgotten them. Did
the
 original D "vision" include them? Why/why not? Is the reason that
they
 haven't been implemented a reason of principle or merely a practical
 one?
The problem is that if they were implemented, then there'd be a need
for
 Koenig lookup.
With you so far
 Once there's Koenig lookup, then there's the export lookup
 madness.
Please explain
I've done some extensive googling for info on export. It seems the main difficulty with export is the ADL. The two phase lookup comes in to play, once when the template is defined and the other when it is instantiated.
The
 second lookup is the ADL one. The ADL can cut across all of the
'translation
 units', meaning an arbitrarilly large number of separate symbol tables
need
 to be analyzed. This is essentially madness.

 As best as I can tell, this problem was not realized when export was voted
 into the Standard, and is the source of many opinions that export is
 unimplementable. EDG proved it could be implemented, reportedly consuming
3
 man years, but I don't hear any more about the alleged advantages of
export
 (code hiding, faster compilation), and hence I suspect those advantages do
 not occur in practice.

 Export is a canonical example of how backwards compatibility with
seemingly
 innocuous design decisions can lead to disaster.

 I do not wish to import that madness into D <g>.
I've not given it enough thought on a global scale, but I can't see how you can expect to get away without ADL, with functions and non-member operators. If this means you must go for export madness, then you'd better get out the white coat.
Jan 06 2004
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:bte1ib$2v71$1 digitaldaemon.com...
 I've not given it enough thought on a global scale, but I can't see how
you
 can expect to get away without ADL, with functions and non-member
operators. ADL is justified by non-member operators. Without non-member operators, no ADL is needed.
 If this means you must go for export madness, then you'd better get out
the
 white coat.
Jan 06 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bte342$31cg$1 digitaldaemon.com...
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:bte1ib$2v71$1 digitaldaemon.com...
 I've not given it enough thought on a global scale, but I can't see how
you
 can expect to get away without ADL, with functions and non-member
operators. ADL is justified by non-member operators. Without non-member operators, no ADL is needed.
Not true. Generalising shims require ADL for a kick off.
Jan 06 2004
parent "Walter" <walter digitalmars.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:bteaea$akr$1 digitaldaemon.com...
 Not true. Generalising shims require ADL for a kick off.
Example?
Jan 06 2004
prev sibling parent davepermen <davepermen_member pathlink.com> writes:
dunno.. i thought thats only for namespaces..

In article <btda5i$1puo$1 digitaldaemon.com>, Walter says...
"Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
news:slrnbvjcbm.69b.jsykari pulu.hut.fi...
 If there are any other valid reasons against non-member operators,
 please bring them forth because I for one have forgotten them. Did the
 original D "vision" include them? Why/why not? Is the reason that they
 haven't been implemented a reason of principle or merely a practical
 one?
The problem is that if they were implemented, then there'd be a need for Koenig lookup. Once there's Koenig lookup, then there's the export lookup madness.
Jan 06 2004
prev sibling parent reply davepermen <davepermen_member pathlink.com> writes:
i don't see how the operator overloading can result in more work to "look up"..

if the parser finds some code snipped like this:

a + b

then it simply translates it to

opAdd(a,b)

directly. and then its just a normal function call.. and done. the normal
operator rules for encoding/parsing code-lines with operators still apply, and
the endresult is pleasing, and with no issues in parsing at all..

class Printer {
Printer print(char[] text) { ...; return this; }
}

Printer opStream(Printer p,char[] text) { return p.print(text); }
Printer opStream(Printer p,int value) { return p.print(toString(value)); }

say opStream is <~ (my lovely token:D)..

then you can write

Printer opStream(Printer p,vec3 v) {
p <~ '(' <~ x <~ ',' <~ y <~ ',' <~ z <~ ')';
}

and a simple piece of code would be like this:

Printer p(stdout);

p <~ "Position: " <~ position;

wich would translate to

opStream(opStream(p,"Position: "),position);

and would then simply decode to

opStream(opStream(Printer,char[]),vec3);

for now, it would be doable with opCall.. (as yet suggested by some).

opStream could get some syntactic sugar, like we don't need to write

StreamerType opStream(StreamerType s,T) {
/* access stream */
return s;
}

but only

char[] opStream(T) {
/* access stream */
return streamlined data packet; // doesn't have to be char[], but in case of io,
you stream with char[] often
}

and

class StreamerType {
opStream(char[] s) {
/* print stream */
}
}


example:

class Printer {
opStream(char[] s) {
printf("%.*s",s);
}
}

char[] opStream(char[] text) {
return text; // just rewrite it to the stream as its the base format.
}

char[] opStream(vec3) {
return <~'('<~x<~','<~y<~','<~z<~')';
}

Printer p;

p <~ "Position: " <~ position;

would translate to

p.opStream(opStream(text) ~ opStream(position));

this thought is not finished, but merely an idea..

but overloadable non-member operators are ESSENCIAL. and i don't see why they
are, at all, different, than what we have now. technically.

In article <slrnbvjcbm.69b.jsykari pulu.hut.fi>, Antti =?iso-8859-1?Q?Syk=E4ri?=
says...
In article <btbv9t$2p2s$1 digitaldaemon.com>, Felix wrote:
 Me too, I find a little weird the syntax Ta.opAdd(Tb) but, if I remember, this
 is the standard way to overload operators in C++, too. Maybe, if cannot be
 simply dropped, an alternative definition will be suitable.
There's no "standard" way in C++, you can pick any way you like. The things that affect your choice are the same with operators and other functions: - only member functions/operators can be overridden in a derived class - only non-member functions can be used to extend the class after it has been closed For example, suppose that the standard output mechanism in D would be something like Printer stdout; void main() { stdout ~ "Hello world " ~ 1 ~ 2 ~ 3 ~ endl; } And Printer implemented something like: class Printer { Printer opCat(int i) { .. } Printer opCat(char[] c) { .. } Printer opCat(Object o) { .. } } [replace Printer with OutputStream if you feel very generic] then the only way to introduce a new printable user-defined type, say Vector3, that isn't derived from Object but still can be printed to stdout is to make a free-standing function: Printer opCat(Printer p, Vector3 v) { p ~ "(" ~ v.x ~ ", " ~ v.y ~ ", " ~ v.z ~ ")"; } That is, if that was possible in D. You can do that in C++. If D was an OO only language, then making types not derived from Object would not be possible and the issue would be moot. Heck, we could be as well programming in Java. But I gather D is supposed be multiparadigm and all that, and you ought to be able to do stuff also without objects if you want. I object to objects. And if there is some template code somewhere, saying "stdout ~ t" where t is of type which is argument for the template, you sure as hell want your Vector3 to be printed instead of getting a message along the lines of "Printer does not have member function opCat(Printer, Vector3). Wanna change it? You can't! Bwahaha!". Duh! So to conclude the rant, I fully agree with davepermen:
 just get rid of it. binary operators don't belong to a member. they
 never did.
and Matthew:
 That's something we need that is supported by a large number of
 issues, not just this one. It's an absolute must, and I can't seee
 Walter escaping us on this one. :)
The only potential problems I see with free-standing operators are: 1. Importing or not importing a module containing operators will affect the way functions are overloaded. "a + b" might mean a different thing after adding an import. On the other hand, normal function calls are already vulnerable for this and I haven't experienced any problems whatsoever. Nor have I had any problems with the issue in C++, where it also exists. 2. The overloading rules might be a tad more complex with freestanding operators. That is, they might require some thinking so that they don't cause any surprises. Maybe there is someone less tired to perform the thinking ;) Complexity doesn't bother me if the rules are sufficiently simple to grasp intuitively. (Unless they end up in some Snake-Tongued Two-Phased Koenig Lookup or similar maze of mirrors) If there are any other valid reasons against non-member operators, please bring them forth because I for one have forgotten them. Did the original D "vision" include them? Why/why not? Is the reason that they haven't been implemented a reason of principle or merely a practical one? By tackling those issues one by one we might even arrive at a solution that satisfies everyone. At least, one can hope... -Antti
Jan 06 2004
parent reply "Walter" <walter digitalmars.com> writes:
"davepermen" <davepermen_member pathlink.com> wrote in message
news:bte3p3$pp$1 digitaldaemon.com...
 i don't see how the operator overloading can result in more work to "look
up"..
 if the parser finds some code snipped like this:

 a + b

 then it simply translates it to

 opAdd(a,b)

 directly. and then its just a normal function call.. and done. the normal
 operator rules for encoding/parsing code-lines with operators still apply,
and
 the endresult is pleasing, and with no issues in parsing at all..
The problem is if opAdd() is defined in another module that is not the current module. It will not be found with the normal scoped lookup. With ordinary functions, one just does: foo.opAdd(a,b) if the function is in module foo. That doesn't work out so good for operator overloads. What ADL does is look at the types of the arguments to the function, and uses those types to add more scopes to look for the opAdd in.
Jan 06 2004
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Walter wrote:
 The problem is if opAdd() is defined in another module that is not the
 current module. It will not be found with the normal scoped lookup. With
 ordinary functions, one just does:
 
     foo.opAdd(a,b)
 
 if the function is in module foo. That doesn't work out so good for operator
 overloads. What ADL does is look at the types of the arguments to the
 function, and uses those types to add more scopes to look for the opAdd in.
Would that even be sufficient? Doesn't one expect to be able to write an opAdd that works on objects whose classes are defined in other modules? I.e. what if the opAdd is in neither of the object modules, but in a completely different one? Seems to me that the only sensible solution is to require that the module opAdd is defined in has to be imported for it to be used. Apply the same rules as in overloaded function calling - it IS only syntactic sugar, after all. import math.vectors; import gnu.bignum; import bigNumIntegration; //defines opAdd(Vector,BigNum) Vector v; BigNum b; v + b; //works only if fancyOperatorModule is imported And if a compatible operator is defined in more than one imported module then a qualified call of the type bigNumIntegration.opAdd(v,b) instead of (v + b) can be used. Those cases should be rare, so no big deal. Hauke
Jan 06 2004
next sibling parent Hauke Duden <H.NS.Duden gmx.net> writes:
Hauke Duden wrote:
 v + b;    //works only if fancyOperatorModule is imported
Sorry, that should have been v + b; //works only if bigNumIntegration is imported
Jan 06 2004
prev sibling next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 Walter wrote:
 The problem is if opAdd() is defined in another module that is not the
 current module. It will not be found with the normal scoped lookup. With
 ordinary functions, one just does:

     foo.opAdd(a,b)

 if the function is in module foo. That doesn't work out so good for
operator
 overloads. What ADL does is look at the types of the arguments to the
 function, and uses those types to add more scopes to look for the opAdd
in.
 Would that even be sufficient? Doesn't one expect to be able to write an
 opAdd that works on objects whose classes are defined in other modules?
Absolutely. And without which, we'll all be hitting ourselves in the head and turning for the C++ compiler.
 I.e. what if the opAdd is in neither of the object modules, but in a
 completely different one?

 Seems to me that the only sensible solution is to require that the
 module opAdd is defined in has to be imported for it to be used. Apply
 the same rules as in overloaded function calling - it IS only syntactic
 sugar, after all.
But what about when you're working with permutations of all kinds of types from potentially unlimited modules, in generic code? D wants to be generic. Therefore D needs ADL. If ADL is hard for compilers, so be it. Those appear to be the breaks.
Jan 06 2004
parent Hauke Duden <H.NS.Duden gmx.net> writes:
Matthew wrote:
I.e. what if the opAdd is in neither of the object modules, but in a
completely different one?

Seems to me that the only sensible solution is to require that the
module opAdd is defined in has to be imported for it to be used. Apply
the same rules as in overloaded function calling - it IS only syntactic
sugar, after all.
But what about when you're working with permutations of all kinds of types from potentially unlimited modules, in generic code? D wants to be generic. Therefore D needs ADL. If ADL is hard for compilers, so be it. Those appear to be the breaks.
I have no idea what ADL is, but wouldn't the same problem also apply to all other overloaded global functions? I think maybe I understand the problem now. Please correct me if I'm wrong: If you write a template that contains a function call to foo(A a,B b), where A and B are template parameters, then this template will be instantiated only once for each combination of (A,B) it is used with. The problem is that if you want to overload foo in a module unrelated to A and B, then the template instance becomes dependent not only on the types A and B, but also on the module where foo is defined. But THAT may be different, depending on where the template is actually used, since different places of usage may import different modules. I do not see how this problem can ever be solved, except by treating templates like macros and simply always compiling it in the context it is used in, every time. But if this isn't solved for "normal" global functions, why does it have to be solved for global operators? Besides, I think the problem should be pretty rare in practice. The only situation where it would cause trouble is if the same template is used with the same two types at two different places in the program, and you have imported a different definition of the operator/global function in one context than in the other. In the case of stream operators and stuff like that, I think that you'll usually have at most one overload for each combination of types. So, can't the calls of global functions/operators inside templates be resolved from the context where the template is instantiated first? That seems to be the only workable alternative to me. Hauke
Jan 06 2004
prev sibling next sibling parent "Ben Hinkle" <bhinkle4 juno.com> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bte5b4$3cq$1 digitaldaemon.com...
 Walter wrote:
 The problem is if opAdd() is defined in another module that is not the
 current module. It will not be found with the normal scoped lookup. With
 ordinary functions, one just does:

     foo.opAdd(a,b)

 if the function is in module foo. That doesn't work out so good for
operator
 overloads. What ADL does is look at the types of the arguments to the
 function, and uses those types to add more scopes to look for the opAdd
in.
 Would that even be sufficient? Doesn't one expect to be able to write an
 opAdd that works on objects whose classes are defined in other modules?
Can't the function dispatch a method call by hand? For example Number opAdd(Number a, Number2 b) { return b.opAdd(a); } Then it is up to Number2 (or a subclass of Number2) to define opAdd. It would be nice to have the compiler's ability to detect if a method exists of a given signature before calling it, though, which would mean some reflection support. I would definitely want to keep all function resolution to things in scope and leave unscoped function resolution to run-time dispatching. That seems the only sane way to go.
 I.e. what if the opAdd is in neither of the object modules, but in a
 completely different one?

 Seems to me that the only sensible solution is to require that the
 module opAdd is defined in has to be imported for it to be used. Apply
 the same rules as in overloaded function calling - it IS only syntactic
 sugar, after all.

 import math.vectors;
 import gnu.bignum;
 import bigNumIntegration; //defines opAdd(Vector,BigNum)

 Vector v;
 BigNum b;

 v + b; //works only if fancyOperatorModule is imported

 And if a compatible operator is defined in more than one imported module
 then a qualified call of the type bigNumIntegration.opAdd(v,b) instead
 of (v + b) can be used. Those cases should be rare, so no big deal.


 Hauke
Jan 06 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bte5b4$3cq$1 digitaldaemon.com...
 Walter wrote:
 The problem is if opAdd() is defined in another module that is not the
 current module. It will not be found with the normal scoped lookup. With
 ordinary functions, one just does:

     foo.opAdd(a,b)

 if the function is in module foo. That doesn't work out so good for
operator
 overloads. What ADL does is look at the types of the arguments to the
 function, and uses those types to add more scopes to look for the opAdd
in.
 Would that even be sufficient? Doesn't one expect to be able to write an
 opAdd that works on objects whose classes are defined in other modules?
Of course. But how member operator lookup works is: a + b If a is an instance of Foo, then Foo.opAdd(b) is looked for. Foo can be in another module. No special ADL rule is required.
Jan 06 2004
next sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:btf3no$1hk9$2 digitaldaemon.com...
|
|
| Of course. But how member operator lookup works is:
|
|     a + b
|
| If a is an instance of Foo, then Foo.opAdd(b) is looked for. Foo can be in
| another module. No special ADL rule is required.
|
|

What if all operators can be reversed? That way, if there's no
Foo.opAdd(typeof(b)), the compiler will look for typeof(b).opAdd_r(Foo).
Also, those who want to possibly extend a stream class, would do
MyType.opAdd_r(Stream). What about that?

-----------------------
Carlos Santander Bernal
Jan 06 2004
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:btfh6d$26rc$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:btf3no$1hk9$2 digitaldaemon.com...
 |
 |
 | Of course. But how member operator lookup works is:
 |
 |     a + b
 |
 | If a is an instance of Foo, then Foo.opAdd(b) is looked for. Foo can be
in
 | another module. No special ADL rule is required.
 |
 |

 What if all operators can be reversed? That way, if there's no
 Foo.opAdd(typeof(b)), the compiler will look for typeof(b).opAdd_r(Foo).
Since add is commutative, the compiler will first look for typeof(a).opAdd, if that isn't found, it will look for typeof(b).opAdd.
 Also, those who want to possibly extend a stream class, would do
 MyType.opAdd_r(Stream). What about that?
I philosophically object to using operator overloading for stream I/O <g>.
Jan 06 2004
next sibling parent reply davepermen <davepermen_member pathlink.com> writes:
what bether thing do you suggest then? with the operators, we get a nice simple
syntax to the way it has to be: for every type-part of the stream, we have an
"addObjToStream" function that gets called, and does exactly the needed work.

D is compile time typed, as is c++. so everything about the type determination
should be compile time. only the needed part, a.k.a. the actual conversion of a
type to the streamformat, should be runtime (if needed:D). and a direct function
per type (and streamtype) would work perfect. not any more runtime overhead than
needed.

but

write(stream,"Hello, my name is ");
write(stream,name);

is clumpsy (while exactly doable currently that way).

and that is why operator overloading would fit in that perfectly. it makes it
possible to chain a lot of such write calls into one rather easy to read line.

if you can think logically, you would not try to judge phylosophically about it.

c++ provides a solution that is typesave, very simple extendable, working with
existing language features, is simple, and can be very fast. the c++ version
possibly isn't. but the D version can.

In article <btfjb9$2a4k$1 digitaldaemon.com>, Walter says...
"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:btfh6d$26rc$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:btf3no$1hk9$2 digitaldaemon.com...
 |
 |
 | Of course. But how member operator lookup works is:
 |
 |     a + b
 |
 | If a is an instance of Foo, then Foo.opAdd(b) is looked for. Foo can be
in
 | another module. No special ADL rule is required.
 |
 |

 What if all operators can be reversed? That way, if there's no
 Foo.opAdd(typeof(b)), the compiler will look for typeof(b).opAdd_r(Foo).
Since add is commutative, the compiler will first look for typeof(a).opAdd, if that isn't found, it will look for typeof(b).opAdd.
 Also, those who want to possibly extend a stream class, would do
 MyType.opAdd_r(Stream). What about that?
I philosophically object to using operator overloading for stream I/O <g>.
Jan 07 2004
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"davepermen" <davepermen_member pathlink.com> wrote in message
news:btgjga$skd$1 digitaldaemon.com...
 what bether thing do you suggest then? with the operators, we get a nice
simple
 syntax to the way it has to be: for every type-part of the stream, we have
an
 "addObjToStream" function that gets called, and does exactly the needed
work. There was an earlier thread about overloading () to implement stream I/O, it works nicely and does not require ADL. It winds up looking like: stdout(arg1)(arg2)(arg3) instead of (in C++): stdout << arg1 << arg2 << arg3 and besides, ADL isn't necessary for the latter either if << is overloaded as a member of stdout.
Jan 07 2004
parent reply davepermen <davepermen_member pathlink.com> writes:
i do understand that. but you simply can't overload your prefered operator for
ANY POSSIBLE TYPE EVER EXISTING. this is just not possible.

free overloadable functions give the ability to add overloads to your stream
without any rewriting of stream or type.

THAT is why i want free operators. they are the way operators behave, and they
are the only way to make streams fast extendable and type save. and FAST.
everyone cries that they have to be faster than the c++ streams. believe me they
can be hell fast. and i can for sure overload all sort of types for my stdout
class and then write stdout << a << b << c; but this is nost scalable.

a library ALWAYS has to provide features a user can use for ANY situation. that
means he has to have a nice plugin-interface. overloadable free operators are a
GREAT plugin-interface for streams.

the by far best.

In article <btglpg$100p$1 digitaldaemon.com>, Walter says...
"davepermen" <davepermen_member pathlink.com> wrote in message
news:btgjga$skd$1 digitaldaemon.com...
 what bether thing do you suggest then? with the operators, we get a nice
simple
 syntax to the way it has to be: for every type-part of the stream, we have
an
 "addObjToStream" function that gets called, and does exactly the needed
work. There was an earlier thread about overloading () to implement stream I/O, it works nicely and does not require ADL. It winds up looking like: stdout(arg1)(arg2)(arg3) instead of (in C++): stdout << arg1 << arg2 << arg3 and besides, ADL isn't necessary for the latter either if << is overloaded as a member of stdout.
Jan 07 2004
parent reply "Walter" <walter digitalmars.com> writes:
"davepermen" <davepermen_member pathlink.com> wrote in message
news:bthndh$2jdb$1 digitaldaemon.com...
 i do understand that. but you simply can't overload your prefered operator
for
 ANY POSSIBLE TYPE EVER EXISTING. this is just not possible.
 free overloadable functions give the ability to add overloads to your
stream
 without any rewriting of stream or type.

 THAT is why i want free operators. they are the way operators behave, and
they
 are the only way to make streams fast extendable and type save. and FAST.
 everyone cries that they have to be faster than the c++ streams. believe
me they
 can be hell fast. and i can for sure overload all sort of types for my
stdout
 class and then write stdout << a << b << c; but this is nost scalable.

 a library ALWAYS has to provide features a user can use for ANY situation.
that
 means he has to have a nice plugin-interface. overloadable free operators
are a
 GREAT plugin-interface for streams.
I understand your point. But there's got to be a better way than ADL.
Jan 09 2004
parent reply davepermen <davepermen_member pathlink.com> writes:
operators have to be in the module you use them (sort of private operators), or
in one of the modules of one of the used types. just as overloadable functions,
more or less..

on the other hand.. the

print(..) { /+ defines this is chainable +/ } // only two dots, like in [x..y]
print(int x) { printf("%i",x); }
print(char[] x) { printf("%.*s",x); }
print(vec3 x) { printf("(%f,%f,%f)",x.x,x.y,x.z); }

etc

wich concatenates

print("Hello World, my Name is ",davepermen," I'm ",19," and i life at
",position);

wich will then map to
print(char[]); // print("Hello World, my Name is ");
print(char[]); // print(davepermen);
print(char[]); // print(" I'm ");
print(int);    // print(19);
print(char[]); // print(" and i life at ");
print(vec3);   // print(position);

and if this is too implicit, possibly we have to call the function more like
this:

print..("Hello World, my Name is ",davepermen," I'm ",19," and i life at
",position); // note the two dots..

or even

print("Hello World, my Name is "..davepermen.." I'm "..19.." and i life at
"..position); // hm, a real stream-chain operator

how to mix that with oo? dunno.. :|

anyways.. lot to think about.. how to make the language flexible extendable
without issues for the compiler?

one word, walter: shit

:D at least you see my points as well.. now lets find some way to work this out.
and then, syntax-sugar it as much as possible:D

In article <btlq6k$2obr$1 digitaldaemon.com>, Walter says...
"davepermen" <davepermen_member pathlink.com> wrote in message
news:bthndh$2jdb$1 digitaldaemon.com...
 i do understand that. but you simply can't overload your prefered operator
for
 ANY POSSIBLE TYPE EVER EXISTING. this is just not possible.
 free overloadable functions give the ability to add overloads to your
stream
 without any rewriting of stream or type.

 THAT is why i want free operators. they are the way operators behave, and
they
 are the only way to make streams fast extendable and type save. and FAST.
 everyone cries that they have to be faster than the c++ streams. believe
me they
 can be hell fast. and i can for sure overload all sort of types for my
stdout
 class and then write stdout << a << b << c; but this is nost scalable.

 a library ALWAYS has to provide features a user can use for ANY situation.
that
 means he has to have a nice plugin-interface. overloadable free operators
are a
 GREAT plugin-interface for streams.
I understand your point. But there's got to be a better way than ADL.
Jan 09 2004
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
Streams are another kind of iterator (input, or output).

It's also another one of those situations that must be extended to any type,
and where the code that controls the iteration (exactly what to print) is
typically written well after the code that deals with each iteration (how to
print each kind of thing) which is written well after the buffering code.
But the later code can't be fast unless the buffering code is spread out
throughout the outer function calls (heavily inlined to the point where the
generated code is just writing bytes directly where they go in the stream
buffer, advancing the buffer pointer or calling to allocate more memory
periodically).

This is hard.  It needs some kind of code injection that you can do in C++
by class wrapping, but not so easily in D (no real dtors, ill-defined order
of shutdown, etc).

Anyway we need to be able to extend it in quite a few different ways.  We
need to be able to add new types that can be input or output, or saved and
loaded, we need to be able to add new types that can act as streams, and
hopefully integrate with the container classes somehow to the point where
you could say:

sys.outstream s;
int c[100];
s.print(c[]);

or, better, something like:

s.print(intersperse(c[], ','));

Sean

"davepermen" <davepermen_member pathlink.com> wrote in message
news:btlt7b$2t6n$1 digitaldaemon.com...
 operators have to be in the module you use them (sort of private
operators), or
 in one of the modules of one of the used types. just as overloadable
functions,
 more or less..

 on the other hand.. the

 print(..) { /+ defines this is chainable +/ } // only two dots, like in
[x..y]
 print(int x) { printf("%i",x); }
 print(char[] x) { printf("%.*s",x); }
 print(vec3 x) { printf("(%f,%f,%f)",x.x,x.y,x.z); }

 etc

 wich concatenates

 print("Hello World, my Name is ",davepermen," I'm ",19," and i life at
 ",position);

 wich will then map to
 print(char[]); // print("Hello World, my Name is ");
 print(char[]); // print(davepermen);
 print(char[]); // print(" I'm ");
 print(int);    // print(19);
 print(char[]); // print(" and i life at ");
 print(vec3);   // print(position);

 and if this is too implicit, possibly we have to call the function more
like
 this:

 print..("Hello World, my Name is ",davepermen," I'm ",19," and i life at
 ",position); // note the two dots..

 or even

 print("Hello World, my Name is "..davepermen.." I'm "..19.." and i life at
 "..position); // hm, a real stream-chain operator

 how to mix that with oo? dunno.. :|

 anyways.. lot to think about.. how to make the language flexible
extendable
 without issues for the compiler?

 one word, walter: shit

 :D at least you see my points as well.. now lets find some way to work
this out.
 and then, syntax-sugar it as much as possible:D

 In article <btlq6k$2obr$1 digitaldaemon.com>, Walter says...
"davepermen" <davepermen_member pathlink.com> wrote in message
news:bthndh$2jdb$1 digitaldaemon.com...
 i do understand that. but you simply can't overload your prefered
operator
for
 ANY POSSIBLE TYPE EVER EXISTING. this is just not possible.
 free overloadable functions give the ability to add overloads to your
stream
 without any rewriting of stream or type.

 THAT is why i want free operators. they are the way operators behave,
and
they
 are the only way to make streams fast extendable and type save. and
FAST.
 everyone cries that they have to be faster than the c++ streams.
believe
me they
 can be hell fast. and i can for sure overload all sort of types for my
stdout
 class and then write stdout << a << b << c; but this is nost scalable.

 a library ALWAYS has to provide features a user can use for ANY
situation.
that
 means he has to have a nice plugin-interface. overloadable free
operators
are a
 GREAT plugin-interface for streams.
I understand your point. But there's got to be a better way than ADL.
Jan 11 2004
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
davepermen wrote:
 what bether thing do you suggest then? with the operators, we get a nice simple
 syntax to the way it has to be: for every type-part of the stream, we have an
 "addObjToStream" function that gets called, and does exactly the needed work.
 
 D is compile time typed, as is c++. so everything about the type determination
 should be compile time. only the needed part, a.k.a. the actual conversion of a
 type to the streamformat, should be runtime (if needed:D). and a direct
function
 per type (and streamtype) would work perfect. not any more runtime overhead
than
 needed.
 
 but
 
 write(stream,"Hello, my name is ");
 write(stream,name);
 
 is clumpsy (while exactly doable currently that way).
 
 and that is why operator overloading would fit in that perfectly. it makes it
 possible to chain a lot of such write calls into one rather easy to read line.
 
 if you can think logically, you would not try to judge phylosophically about
it.
 
 c++ provides a solution that is typesave, very simple extendable, working with
 existing language features, is simple, and can be very fast. the c++ version
 possibly isn't. but the D version can.
It's an irk. I don't see any way to work around it within the confines of D without resorting to polymorphism. The question is merely whether polymorphism is a good way to deal with this. Given that we're talking about something that would (certainly should) be in the standard library, I don't see why not. Making streams deal with PDTs is trivial enough, since they are defined by the compiler, not the code. Dealing with objects is similarly easy: define a Streamable interface, or just use Object.toString(). Structs require a few tiny hoops, but even that's pretty easy: class StreamWrap(T) : IStreamable { this(T t) { _t = t; } void toStream(Stream stream) { stream.write(_t.toStream()); } } The template could further be specialized for reference types and PDTs to provide genericity. Free operator functions would be nice, but it doesn't seem to be the only good way to handle the streaming issue. -- andy
Jan 07 2004
parent reply davepermen <davepermen_member pathlink.com> writes:
but the by far most straightforward and logical way. you don't need delegates as
well, you can do that with a library-implementation. see boost::function.

the trick is, with operator overloading as free functions we get much more
flexibility than only for streams. but there its most obvious. it will be as
fast as directly setting up the specific code for your specific output stream
format manually. (the chain of write(stream,T) calls), wich is the fastest way.
in every other situation, we have to rely on compiler optimisations to _KNOW_
its as fast.

if you don't see that, you don't see encapsulation as something important, then?
because operators don't belong to types, they should never be in their
interface.

In article <bthkn2$2eq0$1 digitaldaemon.com>, Andy Friesen says...
davepermen wrote:
 what bether thing do you suggest then? with the operators, we get a nice simple
 syntax to the way it has to be: for every type-part of the stream, we have an
 "addObjToStream" function that gets called, and does exactly the needed work.
 
 D is compile time typed, as is c++. so everything about the type determination
 should be compile time. only the needed part, a.k.a. the actual conversion of a
 type to the streamformat, should be runtime (if needed:D). and a direct
function
 per type (and streamtype) would work perfect. not any more runtime overhead
than
 needed.
 
 but
 
 write(stream,"Hello, my name is ");
 write(stream,name);
 
 is clumpsy (while exactly doable currently that way).
 
 and that is why operator overloading would fit in that perfectly. it makes it
 possible to chain a lot of such write calls into one rather easy to read line.
 
 if you can think logically, you would not try to judge phylosophically about
it.
 
 c++ provides a solution that is typesave, very simple extendable, working with
 existing language features, is simple, and can be very fast. the c++ version
 possibly isn't. but the D version can.
It's an irk. I don't see any way to work around it within the confines of D without resorting to polymorphism. The question is merely whether polymorphism is a good way to deal with this. Given that we're talking about something that would (certainly should) be in the standard library, I don't see why not. Making streams deal with PDTs is trivial enough, since they are defined by the compiler, not the code. Dealing with objects is similarly easy: define a Streamable interface, or just use Object.toString(). Structs require a few tiny hoops, but even that's pretty easy: class StreamWrap(T) : IStreamable { this(T t) { _t = t; } void toStream(Stream stream) { stream.write(_t.toStream()); } } The template could further be specialized for reference types and PDTs to provide genericity. Free operator functions would be nice, but it doesn't seem to be the only good way to handle the streaming issue. -- andy
Jan 07 2004
next sibling parent reply Andy Friesen <andy ikagames.com> writes:
davepermen wrote:
 but the by far most straightforward and logical way. you don't need delegates
as
 well, you can do that with a library-implementation. see boost::function.
There are lots of reasons not to use boost. It's big and monolithic and doesn't nicely fit into other build systems. Blech. boost::function has an inordinately convoluted implementation as well. (which includes some impressively obfuscated preprocessor hackery, and just plain brute forced template declarations for dealing with up to 50 arguments)
 the trick is, with operator overloading as free functions we get much more
 flexibility than only for streams. but there its most obvious. it will be as
 fast as directly setting up the specific code for your specific output stream
 format manually. (the chain of write(stream,T) calls), wich is the fastest way.
 in every other situation, we have to rely on compiler optimisations to _KNOW_
 its as fast.
 
 if you don't see that, you don't see encapsulation as something important,
then?
 because operators don't belong to types, they should never be in their
 interface.
I'd like to see proof that one more virtual call per nonPDT element being written is going to be unaccetably slow before agreeing that it's the only way. Premature optimization and all that. Fast is good, but one of the main goals of D is to keep Walter from having to turn his head inside out making the compiler work right. Simple compilers also tend to be fast compilers. I'm willing to give a few inches on this subject. As for encapsulation, I do believe that nonmember functions are more encapsulated than member functions, since they are forced to rely on the public interface, and are therefore immune to implementation fluxuations. Operator overloads are a small enough minority that I don't see this as being a particularly important issue. There are far more methods that are not overloading an operator than are. -- andy
Jan 07 2004
parent davepermen <davepermen_member pathlink.com> writes:
davepermen wrote:
 but the by far most straightforward and logical way. you don't need delegates
as
 well, you can do that with a library-implementation. see boost::function.
There are lots of reasons not to use boost. It's big and monolithic and doesn't nicely fit into other build systems. Blech. boost::function has an inordinately convoluted implementation as well. (which includes some impressively obfuscated preprocessor hackery, and just plain brute forced template declarations for dealing with up to 50 arguments)
this was sarcasm, dude! the hackery boost has to do to implement rather good features into c++ is impressive (boost itself is an amazing piece of code! nothing against that). but boost::function can not in any form replace a simple delegate as in D
Fast is good, but one of the main goals of D is to keep Walter from 
having to turn his head inside out making the compiler work right. 
Simple compilers also tend to be fast compilers.  I'm willing to give a 
few inches on this subject.
fully agreeing with the compiler thing. but knowing there is a fast, and theoretically very simple way, to accomplish an in general very fast and proper solution by default, makes me believe its worth fighting for it. i see the issues, but it doesn't remove the fact, that the way c++ allows to write operators give us a great way to make it work without virtual functions.
As for encapsulation, I do believe that nonmember functions are more 
encapsulated than member functions, since they are forced to rely on the 
public interface, and are therefore immune to implementation 
fluxuations.
exactly
perator overloads are a small enough minority that I 
don't see this as being a particularly important issue.  There are far 
more methods that are not overloading an operator than are.
as they are just syntactic sugar, its, imho, entierly WRONG that they ever can access inner parts of an object.. but if its really not possible for walter to find a way he likes it, then its okay.. i still don't see any reason for it. operators and functions are in my eyes, 100% interchangeable. if you can't call a function without specifiyng the package, then you simply can't use such an operator, too.. wouldn't hurt ME at all. as they are just sugar, as i said, yet.
Jan 07 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
<snip>

 if you don't see that, you don't see encapsulation as something important,
then?
 because operators don't belong to types, they should never be in their
 interface.
Well put!
Jan 07 2004
prev sibling parent reply Erik Baklund <Erik_member pathlink.com> writes:
Hi,

Using binary operators like '+', '*', etc. in mathematical expressions is
elegant and desirable. But, for some algebras the multiplicative operation is
not commutative.

Is there a way to model alternative algebras (like geometric algebra) in
D and still be able to make use of the syntactic sugar the operators provide?

In particar, it would be desirable to turn of the commutative property of the
'*' operator.

Kind regards,
Erik




In article <btfjb9$2a4k$1 digitaldaemon.com>, Walter says...
"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:btfh6d$26rc$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:btf3no$1hk9$2 digitaldaemon.com...
 |
 |
 | Of course. But how member operator lookup works is:
 |
 |     a + b
 |
 | If a is an instance of Foo, then Foo.opAdd(b) is looked for. Foo can be
in
 | another module. No special ADL rule is required.
 |
 |

 What if all operators can be reversed? That way, if there's no
 Foo.opAdd(typeof(b)), the compiler will look for typeof(b).opAdd_r(Foo).
Since add is commutative, the compiler will first look for typeof(a).opAdd, if that isn't found, it will look for typeof(b).opAdd.
 Also, those who want to possibly extend a stream class, would do
 MyType.opAdd_r(Stream). What about that?
I philosophically object to using operator overloading for stream I/O <g>.
Jan 07 2004
parent Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
And as well, the additive operation need not be commutative if you
consider '+' to denote the binary operator of a monoid (for which the
set of Java Strings with '+' as binary operator would be an example;
http://mathworld.wolfram.com/Monoid.html)

The commutativity of + and * is in the eye of the beholder.

(By the way, while * in linear algebra is not commutative it is
associative -- (A * B ) * C == A * (B * C) -- so maybe it would be best
denoted by the behavior of the concatenation operator '~'! -- Just
kidding.)

-Antti

In article <bthcg2$21eo$1 digitaldaemon.com>, Erik Baklund wrote:
 
 Hi,
 
 Using binary operators like '+', '*', etc. in mathematical expressions is
 elegant and desirable. But, for some algebras the multiplicative operation is
 not commutative.
 
 Is there a way to model alternative algebras (like geometric algebra) in
 D and still be able to make use of the syntactic sugar the operators provide?
 
 In particar, it would be desirable to turn of the commutative property of the
 '*' operator.
 
 Kind regards,
 Erik
 
 
 
 
 In article <btfjb9$2a4k$1 digitaldaemon.com>, Walter says...
"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:btfh6d$26rc$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> wrote in message
 news:btf3no$1hk9$2 digitaldaemon.com...
 |
 |
 | Of course. But how member operator lookup works is:
 |
 |     a + b
 |
 | If a is an instance of Foo, then Foo.opAdd(b) is looked for. Foo can be
in
 | another module. No special ADL rule is required.
 |
 |

 What if all operators can be reversed? That way, if there's no
 Foo.opAdd(typeof(b)), the compiler will look for typeof(b).opAdd_r(Foo).
Since add is commutative, the compiler will first look for typeof(a).opAdd, if that isn't found, it will look for typeof(b).opAdd.
 Also, those who want to possibly extend a stream class, would do
 MyType.opAdd_r(Stream). What about that?
I philosophically object to using operator overloading for stream I/O <g>.
Jan 07 2004
prev sibling parent davepermen <davepermen_member pathlink.com> writes:
this is great. for OWN TYPES.

i'm still not able to add streaming capabilities to ANY type. types of
libraries, types of a coworker, etc. you can't add streaming capability to some
type without eighter change the stream class (just stupid), or the type class
itself (just as stupid if its not your type).

streaming capability (as any operators actually) physically, and
phylosophically, don't belong to a type. they are an algorithm, working on 2
types, wich they don't belong to. they just use them. that is basic oo, that is
basic encapsulation. you can read a lot about it on cuj.com if you want.

don't make it a memberfunction if you don't need to. that is first rule of real
oo and encapsulation.

In article <btfh6d$26rc$1 digitaldaemon.com>, Carlos Santander B. says...
"Walter" <walter digitalmars.com> wrote in message
news:btf3no$1hk9$2 digitaldaemon.com...
|
|
| Of course. But how member operator lookup works is:
|
|     a + b
|
| If a is an instance of Foo, then Foo.opAdd(b) is looked for. Foo can be in
| another module. No special ADL rule is required.
|
|

What if all operators can be reversed? That way, if there's no
Foo.opAdd(typeof(b)), the compiler will look for typeof(b).opAdd_r(Foo).
Also, those who want to possibly extend a stream class, would do
MyType.opAdd_r(Stream). What about that?

-----------------------
Carlos Santander Bernal
Jan 07 2004
prev sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Walter wrote:
The problem is if opAdd() is defined in another module that is not the
current module. It will not be found with the normal scoped lookup. With
ordinary functions, one just does:

    foo.opAdd(a,b)

if the function is in module foo. That doesn't work out so good for
operator
overloads. What ADL does is look at the types of the arguments to the
function, and uses those types to add more scopes to look for the opAdd
in.
Would that even be sufficient? Doesn't one expect to be able to write an
opAdd that works on objects whose classes are defined in other modules?
Of course. But how member operator lookup works is: a + b If a is an instance of Foo, then Foo.opAdd(b) is looked for. Foo can be in another module. No special ADL rule is required.
Yes, I understand that. But I still don't see how this issue is different from having "normal" overloaded global functions. If I have two modules, foo and bar, each with a different version of function f, and I call f in another module, isn't that the exact same problem, as if f was an opAdd overload and the call an expression of the kind (a+b)? I really don't see how global operators are different from global functions! Hauke
Jan 07 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Hauke Duden wrote:
 Yes, I understand that. But I still don't see how this issue is 
 different from having "normal" overloaded global functions.
Read the manual. Overloads are only possible within one scope. That means, when defined on the module level, overloads only work correctly within that module. If defined within a class, only within a class. And so on.
 If I have two modules, foo and bar, each with a different version of 
 function f, and I call f in another module, isn't that the exact same 
 problem, as if f was an opAdd overload and the call an expression of the 
 kind (a+b)?
The problem is, it doesn't work.
 I really don't see how global operators are different from global 
 functions!
They are not. That's the reason cross-module overloads don't work. They don't work for normal functions. And for operators, it is simply bloody forbidden to use module scope, because it would not make the problem better, just worse! -eye
Jan 07 2004
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Ilya Minkov wrote:
 Hauke Duden wrote:
 
 Yes, I understand that. But I still don't see how this issue is 
 different from having "normal" overloaded global functions.
Read the manual. Overloads are only possible within one scope. That means, when defined on the module level, overloads only work correctly within that module. If defined within a class, only within a class. And so on.
I wasn't aware of that - thanks for explaining. So the problem IS the same with global functions, and it is not solved there either, just circumvented. That doesn't make it any better, though :(. Hauke
Jan 07 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bti1ij$1sv$1 digitaldaemon.com...
 Ilya Minkov wrote:
 Hauke Duden wrote:

 Yes, I understand that. But I still don't see how this issue is
 different from having "normal" overloaded global functions.
Read the manual. Overloads are only possible within one scope. That means, when defined on the module level, overloads only work correctly within that module. If defined within a class, only within a class. And so on.
I wasn't aware of that - thanks for explaining. So the problem IS the same with global functions, and it is not solved there either, just circumvented. That doesn't make it any better, though :(.
Agreed.
Jan 07 2004
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bthrlf$2p6n$2 digitaldaemon.com...
 Hauke Duden wrote:
 Yes, I understand that. But I still don't see how this issue is
 different from having "normal" overloaded global functions.
Read the manual. Overloads are only possible within one scope. That means, when defined on the module level, overloads only work correctly within that module. If defined within a class, only within a class. And so on.
 If I have two modules, foo and bar, each with a different version of
 function f, and I call f in another module, isn't that the exact same
 problem, as if f was an opAdd overload and the call an expression of the
 kind (a+b)?
The problem is, it doesn't work.
Even if you import foo and bar?? I thought that was the whole point of import - to bring symbols into the current scope. Is anyone really suggesting that this mechanism should work *without* requiring import statements?
 I really don't see how global operators are different from global
 functions!
They are not. That's the reason cross-module overloads don't work. They don't work for normal functions. And for operators, it is simply bloody forbidden to use module scope, because it would not make the problem better, just worse!
Again, that is what "import" is for.
Jan 08 2004
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Ben Hinkle wrote:
 Even if you import foo and bar?? I thought that was the whole point of
 import - to bring symbols into the current scope.
 Is anyone really suggesting that this mechanism should work *without*
 requiring import statements?
Import doesn't bring a module into your scope. It only adds it to module search path, used when searching for function calls. All of the overloads of one function must be completed within 1 module. We had been already arguing with Walter about that. And that this approach is, well, at least somewhat "surprising". If you make overloads of one function in one module, and some in another, and import both in yours, only one set of overloads should work. The other should be acessible through the module name point notation only.
They are not. That's the reason cross-module overloads don't work. They
don't work for normal functions. And for operators, it is simply bloody
forbidden to use module scope, because it would not make the problem
better, just worse!
 Again, that is what "import" is for.
Again, you don't seem to listen, nor to read! -eye.
Jan 09 2004
next sibling parent "Ben Hinkle" <bhinkle4 juno.com> writes:
"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:btmmt0$12nl$1 digitaldaemon.com...
 Ben Hinkle wrote:
 Even if you import foo and bar?? I thought that was the whole point of
 import - to bring symbols into the current scope.
 Is anyone really suggesting that this mechanism should work *without*
 requiring import statements?
Import doesn't bring a module into your scope. It only adds it to module search path, used when searching for function calls. All of the overloads of one function must be completed within 1 module. We had been already arguing with Walter about that. And that this approach is, well, at least somewhat "surprising". If you make overloads of one function in one module, and some in another, and import both in yours, only one set of overloads should work. The other should be acessible through the module name point notation only.
Importing a modules adds all the toplevel declarations to the current scope *but* what I had not considered was that functions are not exempt from the rule about ambiguous symbols (which if this is what you mean then yes, I think that is a problem with the language since that is the whole point of function overloading). Using aliases after importing does work with the current language spec, though I was assuming it wasn't needed for functions. For example: file1.d: import file2; alias file2.func func; import file3; alias file3.func func; int main(char[][] args) { func(1); func("hello"); return 0; } file2.d void func(char[] x) { printf("char[] func\n"); } file3.d: void func(int x) { printf("int func\n"); } ugh-ly.
They are not. That's the reason cross-module overloads don't work. They
don't work for normal functions. And for operators, it is simply bloody
forbidden to use module scope, because it would not make the problem
better, just worse!
 Again, that is what "import" is for.
Again, you don't seem to listen, nor to read!
ouch!
 -eye.
Jan 09 2004
prev sibling next sibling parent Lewis <dethbomb hotmail.com> writes:
Ilya Minkov wrote:
 Ben Hinkle wrote:
> Import doesn't bring a module into your scope. It only adds it to module
 search path, used when searching for function calls. All of the 
 overloads of one function must be completed within 1 module.
 
thats good to know, thanks
Jan 09 2004
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
What, do you have to use ..?

with (myalgebra.opAdd)
{
    myalgebra.vecter a,b,c;
    a = b + c;
}

that's the thing with C++, is that all operators are visible all the time,
once they're imported, and the only restriction is that the types have to
match one of the overloads or be convertible.  You could go and choose one
specifically, but you could obtain the same effect by casting the inputs.
Most of the time you want all visible scopes searched for operators, not
only an "outward" search that stops at the first match.

I find this restrictive on enums as well.  I should have to specify a
particular enum type name only if the enum type actually has a name, or only
if there is some conflict and I have to choose.

Please get the visibility rules right.

Sean

"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:btmmt0$12nl$1 digitaldaemon.com...
 Ben Hinkle wrote:
 Even if you import foo and bar?? I thought that was the whole point of
 import - to bring symbols into the current scope.
 Is anyone really suggesting that this mechanism should work *without*
 requiring import statements?
Import doesn't bring a module into your scope. It only adds it to module search path, used when searching for function calls. All of the overloads of one function must be completed within 1 module. We had been already arguing with Walter about that. And that this approach is, well, at least somewhat "surprising". If you make overloads of one function in one module, and some in another, and import both in yours, only one set of overloads should work. The other should be acessible through the module name point notation only.
They are not. That's the reason cross-module overloads don't work. They
don't work for normal functions. And for operators, it is simply bloody
forbidden to use module scope, because it would not make the problem
better, just worse!
 Again, that is what "import" is for.
Again, you don't seem to listen, nor to read! -eye.
Jan 11 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bthrlf$2p6n$2 digitaldaemon.com...
 Hauke Duden wrote:
 Read the manual. Overloads are only possible within one scope. That
 means, when defined on the module level, overloads only work correctly
 within that module. If defined within a class, only within a class. And
 so on.

 If I have two modules, foo and bar, each with a different version of
 function f, and I call f in another module, isn't that the exact same
 problem, as if f was an opAdd overload and the call an expression of the
 kind (a+b)?
The problem is, it doesn't work.
You can make it work by using an alias to overload a function in one module's scope with a function in another module's scope: import bar; void foo(int); alias bar.foo(uint) foo; Of course, this has to be done deliberately rather than implicitly. There isn't a global scope in D, which I think is a good thing when managing very large programs.
May 13 2004
prev sibling parent reply davepermen <davepermen_member pathlink.com> writes:
if we disallow member-operators (wich i don't see useful anyways), then each
operator has an unique name, and can only exist one time. i think you should
simply drop any modularisation for operators. they are syntactic glue, nothing
more.

else we just use a using statement to import the operators of some module.
shouldn't be that hard..

and else, just ADL around.. if needed. the feature is essencial for oo design,
as well as for generic design.

nobody wants to write

output(output(output(output(buffer,"Hello, my name is "),name),", and i come
from "),country);

i see a one-one mapping from function to operator. i see why you don't. but i
think the same rules can simply be applied..

and if you need the operators of some math library, wich you can only access by
math.someFunction, how about this?

with(math) {
a += b;
}

(as a proposed using statement..)

and else..

a math.+= b; doesn't look _THAT_ bad :D

so you would not require the ADL thingy at all.. or too ugly?

In article <bte4a7$1je$1 digitaldaemon.com>, Walter says...
"davepermen" <davepermen_member pathlink.com> wrote in message
news:bte3p3$pp$1 digitaldaemon.com...
 i don't see how the operator overloading can result in more work to "look
up"..
 if the parser finds some code snipped like this:

 a + b

 then it simply translates it to

 opAdd(a,b)

 directly. and then its just a normal function call.. and done. the normal
 operator rules for encoding/parsing code-lines with operators still apply,
and
 the endresult is pleasing, and with no issues in parsing at all..
The problem is if opAdd() is defined in another module that is not the current module. It will not be found with the normal scoped lookup. With ordinary functions, one just does: foo.opAdd(a,b) if the function is in module foo. That doesn't work out so good for operator overloads. What ADL does is look at the types of the arguments to the function, and uses those types to add more scopes to look for the opAdd in.
Jan 06 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 if we disallow member-operators (wich i don't see useful anyways), then
each
 operator has an unique name, and can only exist one time. i think you
should
 simply drop any modularisation for operators. they are syntactic glue,
nothing
 more.
<snip> How so? If you define a String class, and I define a Date class, are you saying that D should not support the ability for us to integrate them into, say, a generic serialisation library? Or to concatenate your string and my string? Or to work with your Transformation function and my Matrix? Is D to be extensible by users, like C and C++, or only by DM, like Java?
Jan 06 2004
next sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Matthew wrote:
 How so? If you define a String class, and I define a Date class, are you
 saying that D should not support the ability for us to integrate them into,
 say, a generic serialisation library? Or to concatenate your string and my
 string? Or to work with your Transformation function and my Matrix?
I think a workaround with RTTI (safe cast) and interfaces can be found for the rare cases where it matters. For example for strings and for the IO streams library. This would also mean that we could have a great advantage, if structs would be able to implement interfaces and could be casted to classes (of the same name) using automatic boxing. You would be advised to look at the library design of such a smart, pure object-oriented, multiple-inheritance, interface-based, add more buzwords here, language as Sather. ;) Bottom line: ADS is not necessary. Non-member operators are not necessary. Some thinking is. -eye
Jan 06 2004
parent davepermen <davepermen_member pathlink.com> writes:
Bottom line: ADS is not necessary. Non-member operators are not 
necessary. Some thinking is.
show me how.
Jan 06 2004
prev sibling parent davepermen <davepermen_member pathlink.com> writes:
unique per type-pair

thats what i ment.

In article <bteaec$akr$3 digitaldaemon.com>, Matthew says...
 if we disallow member-operators (wich i don't see useful anyways), then
each
 operator has an unique name, and can only exist one time. i think you
should
 simply drop any modularisation for operators. they are syntactic glue,
nothing
 more.
<snip> How so? If you define a String class, and I define a Date class, are you saying that D should not support the ability for us to integrate them into, say, a generic serialisation library? Or to concatenate your string and my string? Or to work with your Transformation function and my Matrix? Is D to be extensible by users, like C and C++, or only by DM, like Java?
Jan 06 2004
prev sibling next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
Hear, hear!

"davepermen" <davepermen_member pathlink.com> wrote in message
news:btbq8o$2g9e$1 digitaldaemon.com...
 Walter

 this is essencial. not only for streaming libraries, but simply in
general.. an
 Tc = Ta + Tb doesn't have ANY preference for any of those 3 types. it
should be
 Tc opAdd(Ta a,Tb b) {}

 and not

 Tc Ta.opAdd(Tb b) {}

 or

 Tc Tb.opAddR(Ta a) {}

 or even worse, both!

 just get rid of it. binary operators don't belong to a member. they never
did.
 and if you release that essencial missconcept, and replace it by the only
real
 one, we gain immediate access to a very fast implementable typesave, and
 extendable streaming library..

 Tc operator add(Ta a,Tb b) { }

 would be my prefered way.
Jan 05 2004
prev sibling parent Mark T <Mark_member pathlink.com> writes:
It seems that operator overloads should belong at the module level since they
are really just syntactic sugar for functions.
The module would define and "export" the types then the module would define and
"export" the allowed operators on those types. Since D has strong typedefs this
shouldn't be too much of a problem.
This should also allow operator overload mixtures of standard primitive types
with module defined types. If you need to add more types and operators then the
module needs changing, since you have changed the specification of that module.
Of course, the module should be cohesive but that is up to the developer.

See Ada for a language that has been doing this for a long time:
http://www.grammatech.com/rm95html-1.0/rm9x-06-06.html
http://www.adaic.com/docs/95style/html/sec_5/5-7-4.html



In article <btbq8o$2g9e$1 digitaldaemon.com>, davepermen says...
Walter

this is essencial. not only for streaming libraries, but simply in general.. an

Tc = Ta + Tb doesn't have ANY preference for any of those 3 types. it should be

Tc opAdd(Ta a,Tb b) {}

and not

Tc Ta.opAdd(Tb b) {}

or

Tc Tb.opAddR(Ta a) {}

or even worse, both!

just get rid of it. binary operators don't belong to a member. they never did.

and if you release that essencial missconcept, and replace it by the only real
one, we gain immediate access to a very fast implementable typesave, and
extendable streaming library..

Tc operator add(Ta a,Tb b) { }

would be my prefered way.
Jan 07 2004