ID:2047590
 
BYOND Version:509
Operating System:Windows 10 Pro
Web Browser:Chrome 48.0.2564.116
Applies to:Dream Maker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
The inbuilt byond procs such as Cross(), Uncross() are defined and protected from redefinition (from using /proc) for /atom/movable, but are considered undefined and not protected from using /proc for /atom.

This inherently conflicts with the way all other proc definitions in the language are handled, and though I have not searched explicitly for problems that could result from this, some may theoretically occur.

This may be intended behavior within the language so that you can define these procs for any type, however I think such code runs into the problem of questionable inheritance (and the fact it looks really confusing when such code compiles).

Numbered Steps to Reproduce Problem:
1. Define the base movement procs for /atom and watch the code compile properly

Code Snippet (if applicable) to Reproduce Problem:
/atom/movable/Uncross()
return

/atom/proc/Uncross() This proc definition is not considered in conflict with an inbuilt byond proc definition
return


Expected Results:
To receive the compiler error: conflicts with built-in proc
Ter13 wrote:
This is intended behavior, and defining a like-named proc higher in the type tree should generate an error.

Ah, so you agree with me then, defining Cross() for an atom should generate an error.
In response to Clusterfack
Clusterfack wrote:
Ter13 wrote:
This is intended behavior, and defining a like-named proc higher in the type tree should generate an error.

Ah, so you agree with me then, defining Cross() for an atom should generate an error.

He said higher, /atom would be lower than /atom/movable.
Ah, so you agree with me then, defining Cross() for an atom should generate an error.

Was that was you were saying? I... Couldn't decipher your post then. My bad. Dunno how I flubbed that up. Seems obvious now that I reread it.
Apparently I somewhat misunderstood yours.

But when I said it had 'questionable inheritance' I meant that it is ambiguous as whether an /atom level definition for one of these procs overrode the default behavior for them. It is clear that redefining the /atom/movable level proc would redefine the behavior of the proc, but whether it would inherit from /atom over the byond auto definitions is less so (since they have no explicit definition that I've ever seen beyond the reference).

Similarly you can define /atom/proc/Move(), which gets EVEN MORE confusing since (unless I'm hopelessly out of it today), you call ..() to perform the movement in Move()
/atom/proc/Move(), which gets EVEN MORE confusing since (unless I'm hopelessly out of it today), you call ..() to perform the movement in Move()

Luckily, this is something that I actually understand.

..() isn't the parent seeking first. A supercall from /atom/movable/Move() can never reach /atom/Move() because the supercall will look for the last override on the same object and the default implementation does not perform a supercall.

You can override Move() multiple times on the same object and supercall multiple times between them. Compile order is what determines which definition is reached by supercall.

So at least that bit makes sense.

But yeah, BYOND's actually gotten pretty weird on the compiler end since Tom/Lummox took over and started adding stuff. There's some interesting bugs like viewers being definable as a variable, but causing all kinds of havoc without throwing any errors. Reported that one a few years ago, and it got deferred.
Interesting, yes I have seen that used before but hadn't thought of it being used that way in this context.