Let's say I've got a library that implements a simple function that just spits out "A" into the log.
mob
proc
Herpyderp()
world.log << "A"
And someone else writes a library that overrides this simple function to also spit out "B" into the log.
mob
Herpyderp()
world.log << "B"
Only, this library's author forgot to invoke the supercall, so "A" no longer appears in the log.
And then the user comes along and changes this function to also spit out "C" into the log.
mob
Herpyderp()
..()
world.log << "C"
From the user's perspective, reading the documentation for Library A, and for Library B, mob/Herpyderp() should be spitting out:
A B C
They've done everything right, but they don't know that Library B is at fault. The logical assumption is that Library A is at fault because Library A isn't doing its job and spitting out "A". Library B says it adds "B" to the output, but Library B is inadvertently wrong and is actually overriding Library A's implementation instead of adding to it.
By simply reading the documentation, the user is led to the wrong conclusion, and why would they not go to the author of Library A and ask them why it isn't working?
Library A's author may be able to fix the problem with Library B, but it's just not their responsibility to support Library B. But there's a tool DM has that could prevent this exact chain of events if implemented a little better:
This is the object tree.
Not only is it spitting out ambiguous nodes, it isn't providing a complete picture of your project structure.
mob
proc
HerpyDerp()
world.log << "A"
HerpyDerp()
world.log << "B"
player
The above code looks like this:
Double-clicking on any of these nodes will take you to where it was declared in the code.
The problem, though, is that overriding the same proc in multiple places doesn't leave multiple nodes of the same name, and also leaves overrides outside of the proc filter in the tree.
If we add more code, we see the problem:
mob
proc
HerpyDerp()
world.log << "A"
HerpyDerp()
world.log << "B"
HerpyDerp()
..()
world.log << "C"
player
Notice how I used the same image? Because the output between the two examples is the same. DM simply loses the second override and only keeps track of the first one in compilation order.
Instead, this is how I propose the object tree should look for the above snippet:
This reorganization would make stepping through someone's project faster, and would make the object tree less of a confused mess.
Notice how types are prefixed with /? That's to prevent proc overrides from showing up right next to child types, which is pretty damn confusing if you don't know what you are looking at.
