I think this is about the right time to bring this up.
While it'll probably be some time until (if ever) GML would feature much loved and hated "object-oriented" features, there is a thing that would ease some situations while likely having low implementation cost.
What I propose is a bit of syntactic sugar "method calls".
In short, it would mean that doing
would be roughly equivalent to
On the technical side, it would mean augmenting compiler a little to recognize attempts to call field access (`inst.field`) expressions, and parse them accordingly:
Since GameMaker does not allow calling scripts stored in arbitrary expressions via `expr()`, there is no ambiguity in syntax.
As far as runtime side of things goes, things look like they should be easily doable too - both JavaScript and YYC pass "self"\"other" pointers as function arguments, meaning that a context swap for a script call is easy and fast enough to do. It is harder to tell about VM (push context - get value - call - pop context?), but a separate "get & call" bytecode instruction could be introduced in worst case.
As proof of concept, I've implemented the feature in GMLive this afternoon -- live example. Code:
While it'll probably be some time until (if ever) GML would feature much loved and hated "object-oriented" features, there is a thing that would ease some situations while likely having low implementation cost.
What I propose is a bit of syntactic sugar "method calls".
In short, it would mean that doing
Code:
inst.method(1, "hi");
Code:
with (inst) script_execute(method, 1, "hi");
if field name matches a built-in function name,
if the function makes use of caller instance (instance_destroy versus show_message),
else if field name matches a script name,convert to a function call upon the instance.
else show error (for the lack of sense in the act).convert to a script call upon the instance.
else convert to value retrieval and script call of it upon the instance.Since GameMaker does not allow calling scripts stored in arbitrary expressions via `expr()`, there is no ambiguity in syntax.
As far as runtime side of things goes, things look like they should be easily doable too - both JavaScript and YYC pass "self"\"other" pointers as function arguments, meaning that a context swap for a script call is easy and fast enough to do. It is harder to tell about VM (push context - get value - call - pop context?), but a separate "get & call" bytecode instruction could be introduced in worst case.
As proof of concept, I've implemented the feature in GMLive this afternoon -- live example. Code:
Code:
var q = instance_create(0, 0, obj_blank);
q.name = "GMLive";
q.greet = scr_greet;
q.scr_greet(); // `GMLive says "hi"`
q.greet(); // `GMLive says "hi"`
q.instance_destroy();
#define scr_greet
show_debug_message(name + ' says "hi"');