Operator overloading

ID:107902
 
Feb 1 2011, 4:24 pm
Resolved
Operator overloading is now possible for most, but not all, operators.
Applies to:DM Language
Status: Resolved (512.1386)
This issue has been resolved.
I imagine this is going to get deferred pretty quickly, but if DM ever gets some significant new features, the ability to overload operators would be great. For example:
vector/operator
  +(vector/a, vector/b)
    return new/vector(a.x + b.x, a.y + b.y)

mob/verb/test()
  var/vector
    a = new(1, 2)
    b = new(3, 4)
    c = a + b
  usr << "c = ([c.x], [c.y])" // outputs 'c = (4, 6)'


This was mentioned a while ago on the forums by Audeuro.
Feb 3 2011, 3:58 pm
For a beginner-friendly language like DM I think it's best to not have features like this. The syntax looks nice if you know what's happening, but to others it just obscures the meaning of the + operator.
Feb 3 2011, 4:10 pm (Edited on Feb 3 2011, 4:17 pm)
What do you mean? I don't see how a + b is any less clear to anyone (beginner or not) than a.Add(B). I don't love the proposed syntax for defining an operator, but there are certainly more complicated concepts already in DM. And since a beginner wouldn't be forced into using this feature, it wouldn't really affect them anyway.

Plus, since when are features left out just because they could be confusing to beginners? A beginner should pretty much never use goto, but it's still in the language. Even VB allows you to overload operators. In any case, I thought a big part of the new site update was to attract older, more experienced developers, which would suggest that DM shouldn't be targeting new programmers specifically.
Feb 4 2011, 3:09 am
Overloaded operators obscure the meaning of the code. It's clear that a.Add(b) calls a proc.

I can't defend their choice to include goto, but having one feature whose use is discouraged doesn't justify the addition of another. Look at how well people do when they're told to not use usr. Even though people aren't forced to use it, it still causes confusion.
Feb 4 2011, 4:48 am
Frankly any language that leaves out goto does the user a disservice. There are some situations that simply demand it. Java for instance supports goto in its bytecode, but not in the language, and for no other reason than stupid ideology. Goto is basically the equivalent of a narcotic--easily abused, but necessary for some cases when administered by a qualified person.
Feb 6 2011, 8:23 am (Edited on Feb 6 2011, 8:29 am)
I am aware this was deferred, but I am still interested in why operator overloading is discouraged. If anything, it makes less mathematical sense to restrict operators to just real numbers. I personally find operator overloading extremely convenient at times. I understand how usr and goto can be abused, but I'm not sure we should be placing operator overloading in the same class as these. It is confusing - yes - but not more than a "toString" method or the difference between int and double division in other programming languages - and beginner programmers handle those fine. Besides, we already have a kind-of built-in operator overloading, say set operations on lists, or using "+, -" on lists.
Feb 6 2011, 7:31 pm
I think operator overloading could be done, and probably wouldn't be too difficult aside from handling the syntax. The big problem is the syntax. I'd have to really get into the guts of the parser to know if something like operator+ was even possible, but my guess is something a lot simpler would have to be picked.

Overall though I like the idea. It's the kind of feature request that normally gets put on the back burner because it's such a big change to the way things are done, and it'll need a solid syntax to have any hope of implementation, but if the latter hurdle can be overcome then the former is mostly an issue of whether Tom considers it worth implementing.

Questions worth considering: How would you differentiate between the unary and binary - operators? What format would you choose for telling the difference between prefix and postfix versions of ++?

Also, there would have to be some common-sense limitations. Right now I believe datums for instance don't work at all with < and > (though I could be wrong about that), but == and != definitely have an important meaning and those wouldn't be overloadable. Comparing references in this way would have to remain as-is because otherwise I think it would throw everything into chaos. Likewise obviously = itself wouldn't be overloadable, though something like += would make sense.
Feb 7 2011, 8:29 am (Edited on Feb 7 2011, 9:04 am)
Lummox JR wrote:
Questions worth considering: How would you differentiate between the unary and binary - operators?

Unless what Toadfish suggested is feasible, since DM doesn't support method overloading (well, unless you count the args list), the best way I can think of is by passing a third argument (assuming the syntax in the request above were used).

What format would you choose for telling the difference between prefix and postfix versions of ++?

To keep things consistent, you shouldn't be able to (this is how C# works).

Also, there would have to be some common-sense limitations. Right now I believe datums for instance don't work at all with < and > (though I could be wrong about that), but == and != definitely have an important meaning and those wouldn't be overloadable. Comparing references in this way would have to remain as-is because otherwise I think it would throw everything into chaos. Likewise obviously = itself wouldn't be overloadable, though something like += would make sense.

I don't think you should be able to explicitly overload any assignment operator. a += b should always be the equivalent of a = a + b. You would have to overload the + operator in order to change the behavior of +=.
Feb 7 2011, 8:41 am
This seems like it falls into the same boat as this. Something that we can easily and more straightforwardly do ourselves with a proc, that would over-complicate/confuse the basics of the language if built-in.
Feb 7 2011, 8:42 am (Edited on Feb 7 2011, 9:09 am)
I had another post here. For some odd reason (network shenanigans) I couldn't edit my post, and my edit deleted most of it. I deleted the thing altogether - just don't ask.

Reading Nickr5's post, I think going the C# way about ++ or -- makes more sense than the C++ way. I'm still not sure how logical all of this is going to be without comparison operators, though.

I forgot DM doesn't have method overloading (which is a shame, by the way). About the - operator, then, I'll have to agree with Nick about the third argument. It might also simply make sense to make the first argument null in the unary case. Lastly, I like the idea of having a default '0' you can specify ("" for strings, (0,0) for 2D vectors), too, such that all (-x)s become ('0' - x), but that sounds like more trouble than it's worth.
Feb 8 2011, 3:09 am
Without being able to overload += you are actually losing out on a lot. Assignment operators are easier to define because they modify the object directly. The + operation might have to make a copy of the object and modify that. For example, look at BYOND's lists:

var/a = list(1,2,3)
var/b = a + 4
a += 4

The second line has to create a copy of a then append to it. By using the += operator you can directly append to a. Not only are these side effects costly, I'm not sure there's a simple way to correctly create a copy of an object without creating more strange and messy side effects.
Sep 25 2017, 12:57 pm
Lummox JR resolved issue with message:
Operator overloading is now possible for most, but not all, operators.
Oct 12 2017, 9:21 am
In response to Lummox JR
Lummox JR wrote:
Lummox JR resolved issue with message:
Operator overloading is now possible for most, but not all, operators.

How to do it? I cannot find it in the documentation. Is it possible for [] operator?
Oct 12 2017, 9:24 am
In response to Kisioj
It is in the documentation. Download 512, open up the reference, and it's right there in the operator section.

You can indeed overload the [] operator, but there are separate procs for reading and writing because of the fact that DM doesn't use pointers.