ID:2319377
 
Applies to:Dream Maker
Status: Open

Issue hasn't been assigned a status value.
I frequently am asked to delve into problems with my libraries that aren't problems with my libraries. 9 times out of 10, it's someone overriding someone and forgetting to invoke a supercall, or including a library that was written by some misguided soul that just assumed that nobody would include anything before it.

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.
Hmm. I'd have to see what the object tree makes available there. It's been a while since I looked at object tree generation code.
I've taken another look at this (much later than intended), and it appears that making multiple nodes for proc overrides may be doable. Moving items in the tree is a much nastier situation.

The tree is being built by Dream Maker in the exact same way the compiler sees it. It goes through each top-level node, recurses through and builds the tree on the fly, then cleans up unused nodes later. The tree doesn't take parent_type or anything like that into account, either.

To move things around--and TBH I think there's a better case to be made for merely adding a copy of the node under the proc definition rather than moving it--would entail giving DM more awareness of parent_type organizations at that stage and would also require that it scan the whole tree, then add duplicate nodes (or move them, but I prefer duplicates) after it builds the tree and before deletion.

From where I'm sitting it looks doable, just challenging.