Question - Code Overriding built-in functions/constants - intended?

[Alice]

At least as of 2.0.5.77, it is apparently possible to override built-in functions and constants by creating same-named scripts.

Is that effect intended (to be fair, it can be useful in some specific cases, though one must take care not to overuse it)?

And if it is, is there a way to access the original built-in function? Also, if it's intended, the compiler should not require the number of arguments associated with the original function.

 

[rui.rosario]

I remember GM 8 had this, and it was really useful under certain conditions, although I'd say to keep the restriction of the original arguments, as you should only really replace them if you intend to offer the "same" logic.

For example, you can use show_debug_message in your game and for the final release just replace it by an inline empty script (removing the calls) or a script that logs the messages to a file.
However, the intent is still to show a debug message (in the first case there is no debug message since it is a final release, in the second case the debug message is stored in a log).

 

[csanyk]

That's interesting that GM8 had the capability. I know that at a certain point, GMS1.x would start warning you about name conflicts. (I found this out when a script that I had written suddenly caused an error after I updated GMS to a version that had introduced a GML function of the same name.)

It also used to be in GM8 that you could have assets of different types, with the same name. Eg, you could have a sprite resource and an object resource both named "Player".

Being able to override built-in GMS functions and constants seems like it could be dangerous/misleading if you're reading a code snippet without realizing that the reserved words aren't working as normally expected due to being overridden. For this reason, I think I'll avoid using it if I can avoid it. But it might be nice to be able to repurpose reserved words with scripts that do what you want them to do, I guess.

 

[Alice]

As for arguments restrictions: actually, getting rid of them can be pretty useful to expand upon a function; e.g. make overloads that treat some parameters as optional, or allow additional parameters that are handled in additional logic.

Either way, assuming the built-in functions/constants overriding is intended, I'm going to reiterate:
Can you allow overrides to take arbitrary number of arguments?
Is it possible to access the original built-in function, even if the override is present?

@Mike @rwkay ?