ID:2297934
 
Resolved
Operator overloads didn't apply to datum-derived types like obj, mob, etc. In addition, output and input can be overridden now.
BYOND Version:512.1387
Operating System:Windows 10 Home
Web Browser:Chrome 60.0.3112.113
Applies to:DM Language
Status: Resolved (512.1390)

This issue has been resolved.
Descriptive Problem Summary:
demo
var v = 3
proc/operator+(demo/o)
return v + o.v

mob/verb/TEST1()
var demo
a = new
b = new
world << (a + b)

mob
proc/operator+(mob/m)
return name + m.name

mob/verb/TEST2()
var mob
a = new
b = new
world << (a + b)


Results:
TEST1 returns 6 as intended.
TEST2 results in a runtime
runtime error: type mismatch: the mob (/mob) + the mob (/mob).

When does the problem NOT occur?
When using datums.
Ah. I actually should have specified in the operator overloading that it was never intended to be used for mobs and such. I'm not sure it'd be worthwhile to try adding those, especially because overloads on some operators (like <<) would actually break things for them.
What if we combined the << shift/output operator overloads?

Implement a built-in mob.Output(), client.Output(), mob.PlaySound(), and client.Playsound() procs.

This would allow developers to not only trap when sounds and messages were sent to mobs/players, but it would solve this problem and allow operator overloads to be a lot more consistent.

Yes, it would make the << operators a single contextual operator, but I don't see a problem with that.

mob/PlaySound() and mob/Output() would by default check if a client existed and if it did, call the client variant.

The default action of the mob/client output/playsound procs would perform the default operation the operator currently does.

The only operator that's left would be the savefile << / >> operators, for which you could add write()/read() to savefiles. These would be different than Write()/Read() in that savefile.write() and savefile.read() are instructions, not hooks.
I've decided to go ahead with changes that will make overloading available beyond /datum itself. This seems reasonable, as all atoms are ostensibly datums and preventing overloads just because of an internal distinction seems silly.

Also while input via operator>> wasn't previously supported, I felt it important to add that.
Lummox JR resolved issue with message:
Operator overloads didn't apply to datum-derived types like obj, mob, etc. In addition, output and input can be overridden now.