OFFICIAL GML Updates in 2019 (Follow up AMA)

Status
Not open for further replies.
GML QUESTION:

Will there be destructors for the delete operator?
Code:
function MyAlgorithm()
{
    // constructor
    data = ds_map_create();

    // destructor
    delete = function() {
        ds_map_delete(data);
    }
}

var alg = new MyAlgorithm();
delete alg;
Sure you can also write:
Code:
var alg = new MyAlgorithm();
alg.delete();
delete alg;
Or wait for the garbage collector. But I personally prefer to just clean up and let the GC do as little work as possible.
The “future implementations” said that lightweight object would be “just like objects but with no events just constructor and destructor methods”. Two weeks ago the text was edited and they removed the destructors part! So I guess ... NO! (but I really wish they do... unless they plan to reimplement data structures with OOP approach in the future)

by the way I asked the same exact question last week and there was no response from YYG either so I hope we have a response this time around.
 
Last edited:
In fact the above is a very good question. And from what I saw already, there's no destructors (a constructor is just a whole struct/function body). There's a "delete" operator, but seems that when using ds_xxx structures inside structs we gonna create massive memory leaks, cause there's no difference between:
Code:
var s = {a: ds_map_create();}
and:
Code:
var s = {a: 1}
And there's no way to unset ds_xxx created that way, except of remembering to remove it before delete:
Code:
ds_map_delete(s.a);
delete s;
And if there's garbage collector for structs (which I believe is) - then it can be really misleading.
That would be fixable with destructors... and should not be that hard...

Code:
delete a
could call a hidden method, something like “__delete” that would exist inside the object by default and could be override for example.

Code:
struct a {
   list = ds_list_create();
   __delete = function() { ds_list_destroy(list); }
}

var t = new a(); // would create instance with new list 

delete t; // would call __delete destroying the list
regarding the struct declaration I used above I’m just guessing since they said lightweight objects real name are “structs” so.
 
Last edited:

Yal

🐧 *penguin noises*
GMC Elder
"struct" and "class" are interchangeable in C++ (including you being able to define methods for a struct) so there's nothing that weird with the rebranding. Probably feels more familiar to people with a real-language programming background than "light-weight object" or "lwo", and that's always a plus (there's still regular cases of someone declaring what they thought were instance variables with var and then wondering why all their data keeps getting undefined)
 

gnysek

Member
regarding the struct declaration I used above I’m just guessing since they said lightweight objects real name are “structs” so.
Yeah, but AFAIK there will be two types of structs, so it's hard to say which one are "don't call them LWO":

Code:
struct first_type = {a: 1};
function second_type() {a = 1}; // you can use "new" with this one
Not sure if this will be in final version, and the second is more similar to "class", but having using different keyword and changing : to =, then calling them both "structs" sounds weird. And after above concers I hope they gonna add a destructor function too, as we proved that there can be one-liner which creates massive memory leak.
Maybe they also found those issues and that's why it's postponed...
 
Yeah, but AFAIK there will be two types of structs, so it's hard to say which one are "don't call them LWO":

Code:
struct first_type = {a: 1};
function second_type() {a = 1}; // you can use "new" with this one
Not sure if this will be in final version, and the second is more similar to "class", but having using different keyword and changing : to =, then calling them both "structs" sounds weird. And after above concers I hope they gonna add a destructor function too, as we proved that there can be one-liner which creates massive memory leak.
Maybe they also found those issues and that's why it's postponed...
a way I see for using struct declaration in a more consistent way (without having two keywords for the same thing) is using the same approach they used for functions (there are anonymous ones and global ones). The concept on structs COULD be:

ANONYMOUS (not highlighted)
Code:
var my_quick_struct = struct {
    a: 10,
    b: “attack”
};
or (omitting the keyword altogether)
Code:
var my_quick_steuct = { a: 10 ...}
No different color syntax in the IDE, could not use “new”, cannot pass arguments.

GLOBAL (highlighted, can use new)
Code:
struct my_global_struct() {
    a = 10;
    b = “attack”;
}
Similarly to global functions, could create a different color syntax for the named struct allowing for global differentiation and allowing for using new.


To be more clear the first one is a struct used as an expression and the second one a structure used as a statement. you are should NOT be able to directly assign the second one to a variable.

ILLEGAL example:
Code:
var a = struct my_global_struct() {...}

Regarding the “can use new” thing. I think the compiler should allow for using new on a variable for example.
Code:
struct my_global_struct() {...}
var a = my_global_struct;
var c = new a();
Would be great to allow such a thing.

NOTE: remeber this is just a personal opinion on a way I think would make struct declaration more consistent.
 
Last edited:

Nux

Member
Code:
struct first_type = {a: 1};
function second_type() {a = 1}; // you can use "new" with this one
[..] then calling them both "structs" sounds weird.
That is because the second one is not a struct.

I don't think there will be a struct keyword (even though it is a reserved word) and Nocturne was just referring to calling the "lightweight objects" themselves structs, i.e.
Code:
var my_struct = {
    message : "hello world",
    value : 5
};
would create a struct and store it inside the variable
my_struct.

Additionally...
Code:
function Vec2(_x, _y) {
    x = _x;
    y = _y;
}
would not be a "struct", but a constructor. (If any of you are familiar with object oriented programming languages.)
In other words, a function which populates a struct with values.
 

gnysek

Member
would not be a "struct", but a constructor. (If any of you are familiar with object oriented programming languages.)
In other words, a function which populates a struct with values.
OK, name we can use then name "function constructor for making structs". What I wanted to highlight, is that this constructor may look too similar to regular functions, with no similarity to structs - which isn't easy to learn for newbies. The only common part will be that we're getting values by using <structname>.<structvalue> later in code. But people may then try to access values of regular functions this way too and don't understand why it's not working.
Also, to make more mess:

Code:
function A() constructor {
    a = 5;
    b = function() {return true;}
}

function B() {
   return {a: 5, b: function() {return true;}}
}

var a = new A();
var b = B();
And both functions returns structs... The only difference is that first have inheritance (for definition) and should allow to check that two structs are of same type, while second just allows to read values. For me, not a big problem, I was just thinking about learning new people, as I'm thinking about getting back to teaching GML in schools again. They might not understand the difference if they never programmed anything.

The issue here is that as YYG remains completely silent about 2.3, so even if some syntax woulnd't seem to look friendly to us, they won't change it, as they already choose and will get a finalized version in open beta (so we can only report a bugs in what we get).
 
Additionally...
Code:
function Vec2(_x, _y) {
x = _x;
y = _y;
}
would not be a "struct", but a constructor. (If any of you are familiar with object oriented programming languages.)
In other words, a function which populates a struct with values.
I'm familiarized with that for almost 15 years now :) the problem is that a great percent of the GMS community are not programmers and I do think YYG want to keep GMS2 an easy to use and understand product. While we could argue that that's how JS works for example, we must admit that sometimes JS could be cleaner (that's also why a lot of JS based languages rose in the last years to try to clean a little the mess around the syntax).

but looking again at some code imagine this:

Code:
function log(message) {
    text = message;
    show_debug_message(text);
}
There will be people in the forums asking:
"Do I have to delete the log message after using it?"
Code:
a = new log("hello")
delete a; // ???
"Can I set the message whenever I want?"
Code:
a = new log("hello")
a.text = "new message";
"What do I have to do to display the new message?"
Code:
a = new log("hello")
a.text = "new message";
a();
this will be tricky and harder to explain and will be a lot more prone to errors, even for some people who are veterans in OOP.
Because even from a OOP veteran point of view both are valid.
Code:
var a = new log("hello");
// this one when called will create a new struct and print the message to the debug window
// latter you can access its member using the DOT accessor. "a.text";
// will create a memory foot print as it is not intended to be used this way.

var a = log("hello");
// this one will print the message to the debug window
// and create an instance variable where ever it was called from named text with the argument value.
// doesn't return a thing which in GML is actually not true it always returns 0

Another nice example will be this and I'm curious to know the outcome of this type of thing:
Code:
function add(num1, num2) {
    return num1 + num2;
}

var s = new add(4, 5); // what will this return?!
My guess is an empty struct and that's probably the most accurate guess but good luck explaining it to the 80% of the forums/discord users. ;)

OK, name we can use then name "function constructor for making structs". What I wanted to highlight, is that this constructor may look too similar to regular functions, with no similarity to structs - which isn't easy to learn for newbies. The only common part will be that we're getting values by using <structname>.<structvalue> later in code. But people may then try to access values of regular functions this way too and don't understand why it's not working.
Also, to make more mess:

Code:
function A() constructor {
a = 5;
b = function() {return true;}
}

function B() {
return {a: 5, b: function() {return true;}}
}

var a = new A();
var b = B();
And both functions returns structs... The only difference is that first have inheritance (for definition) and should allow to check that two structs are of same type, while second just allows to read values. For me, not a big problem, I was just thinking about learning new people, as I'm thinking about getting back to teaching GML in schools again. They might not understand the difference if they never programmed anything.

The issue here is that as YYG remains completely silent about 2.3, so even if some syntax woulnd't seem to look friendly to us, they won't change it, as they already choose and will get a finalized version in open beta (so we can only report a bugs in what we get).
Another great example, this will be hard to teach!! :)
 
Last edited:

gnysek

Member
My guess is an empty struct and that's probably the most accurate guess but good luck explaining it to the 80% of the forums/discord users. ;)
That's should return exception in fact, as constructors for sure will have it's own keyword to differentiate them from regular functions. That's confirmed by my secret squirrel agents squad :squirrel: .

I just noticed that word "constructor" have a word "struct" in it :D That funny coincedence might be usable in teaching :p
 
That's should return exception in fact, as constructors for sure will have it's own keyword to differentiate them from regular functions. That's confirmed by my secret squirrel agents squad :squirrel: .
Ohhh that's awesome news!!
Now I wish I had a secret squirrel agents squad xD
 

Henry00

Member
I believe this was simply the most trivial way for them to implement this new feature into the existing GML parser/compiler.

"We have scripts and instances."
"1. Let's allow defining scripts with named arguments." - functions.
"2. Wait, now we can just have multiple functions in one file!" - multiple functions in a script.

- the next day -
"3. Let's allow assigning a function reference to a variable." - reference functions and callbacks.
"4. Wait, let's do that by default when you define a function in an instance!" - member functions.
"5. In fact, we can also assign anonymous functions without a name to a variable!" - anonymous functions.

- the next day -
"6. Man, instances sure are cool, they are almost like classes... I hear some people abuse instances as such..."
"6. Let's just try introducing objects without events then, can't call them instances, maybe uhh lite-weight object then??" - structs.
"7. Alright but there's no way to create them. Well we have scopes in GML using additional { } parenthesis, maybe we can change self to a new lite-weight object? Wow that's cool!" - introducing { _x = 5; } syntax."
"8. Well, you can only create a single lite-weight object like this unless you put the code inside of a function, but that would look so weird:
Code:
function test()
{
return {
_x = 5;
}
}
"9. Well, let's just introduce a new keyword to automatically set self to a new lite-weight object."
Code:
function test()
{
    _x = 5;
}
- the next day -
"10. Maybe people will prefer to call it structs, they sure are similar to that, let's call it that now."

And all of this works using the old existing technology without having to invent anything new, likely only introducing minor changes for all platforms.
 

Henry00

Member
Those "minor" changes costed us a huge delay already --' :p
Well they did decide to introduce "a fully multi-threaded, multi-generational garbage collector that handles the lifetime of all variables and instances inside the GMS runtime" just because cleanup work is a pain, lists in structs in grids without destructors. :p
 
Well they did decide to introduce "a fully multi-threaded, multi-generational garbage collector that handles the lifetime of all variables and instances inside the GMS runtime" just because cleanup work is a pain, lists in structs in grids without destructors. :p
Correct me if I'm wrong but there will be no garbage collector for ds_list, ds_grid, ds_map.... the garbage collector only works for anonymous functions/ arrays/ structs.
At least for now.. you'll still need to destroy them (data structures) yourself.
 

gnysek

Member
Yeah, there was no confirmation, that there will be GC for ds things now. I think, it will be in 2.4, as this is mostly a breaking change - some games depends on integer numbering of resources, and if they want to add a proper GC, then all sprites, rooms, objects, ds_xxx and all that stuff need to became a type named "resource", so you can't do anymore "1 == sprite1". Now it's possible to just put some sprite/room/object at end of resource tree, and then make
Code:
for(i=0; i<resource_name; i++)
and iterate over all resources, as they have id from 1 to N. After introducing garbage collector and "resource type" - that won't be possible. So this is again bigger change and introducing both at one could be too much. But it's on their official list, so hope they still plan it.
 

Henry00

Member
Correct me if I'm wrong but there will be no garbage collector for ds_list, ds_grid, ds_map.... the garbage collector only works for anonymous functions/ arrays/ structs.
At least for now.. you'll still need to destroy them (data structures) yourself.
Ah! You are right! I got a little too excited there! :oops:
Well, back to writing lots of loops in the cleanup event... ;)
 

Nux

Member
constructors for sure will have it's own keyword to differentiate them from regular functions
Although you are correct about the constructor keyword. You shouldn't go spreading that information.

I think the topic should stay focused on what we publicly know.

-

Code:
function add(num1, num2) {
    return num1 + num2;
}

var s = new add(4, 5); // what will this return?!
Yes, it will return the empty struct, but I don't find this to be any more "error prone" than almost anything else in GameMaker.

For example, using prefixes just so we know the correct resource to use in certain situations:
Code:
draw_sprite(x, y, obj_player);
If you're not correctly reading your code, then both of these issues are a result of the same thing and they both produce undefined behaviour.
 
Although you are correct about the constructor keyword. You shouldn't go spreading that information.

I think the topic should stay focused on what we publicly know.

-



Yes, it will return the empty struct, but I don't find this to be any more "error prone" than almost anything else in GameMaker.

For example, using prefixes just so we know the correct resource to use in certain situations:
Code:
draw_sprite(x, y, obj_player);
If you're not correctly reading your code, then both of these issues are a result of the same thing and they both produce undefined behaviour.
Though I understand what you are saying, Builtin function have help and tool tips that in some way help avoiding those errors.
Using new or not goes way beyond that.. looking at some code just that line and recurring only to screen info you cannot know if that function should be called or instantiated ;)

great to know the struct keyword is there.. and you pulling @gnysek ears just underlined it even more ;)
 

Yal

🐧 *penguin noises*
GMC Elder
Yeah, there was no confirmation, that there will be GC for ds things now. I think, it will be in 2.4, as this is mostly a breaking change - some games depends on integer numbering of resources, and if they want to add a proper GC, then all sprites, rooms, objects, ds_xxx and all that stuff need to became a type named "resource", so you can't do anymore "1 == sprite1". Now it's possible to just put some sprite/room/object at end of resource tree, and then make
Code:
for(i=0; i<resource_name; i++)
and iterate over all resources, as they have id from 1 to N. After introducing garbage collector and "resource type" - that won't be possible. So this is again bigger change and introducing both at one could be too much. But it's on their official list, so hope they still plan it.
Data structures and game resources being the same thing?!?! I dunno what you've been smoking, but you probably should keep it a secret from the cops :p Let's just think about a bunch of cases where garbage-collecting resources doesn't make sense...
  • When would you garbage-collect a room? When there's no way you could reach it from code? This would mean a game with room_goto_next() couldn't garbage-collect any room, unless it can be proven that that code can't be executed from the preceeding room. To prove that, you need to check all instances and scripts (depending on where you have room_goto_next references) and verify no instances of an object that has room_goto_next in any event can be spawned, or that no script_execute() call can call a script that does it.
  • If rooms, objects or sprites get garbage-collected, what happens if you restart the game? Will the game just crash if they're gone, or will it stop and re-load the data from the disk, thereby eliminating any speed and memory benefits garbage-collecting them provided?
  • Even if resources are re-loaded on game restarts, their IDs would not be unique anymore if newly created resources (sprite_add_from_surface etc) were occupying the slots freed up by garbage-collecting them - which they will do since the only reason to garbage-collect resources is to free up those spots of memory for new stuff - and the game would have to re-map any references to the old resources after re-loading all the GC'd resources.
  • It would be impossible to tell what could be referenced by asset_get_index when procedural strings (and data saved in files, etc) are involved.
  • Code storing asset data in buffers would break if references are replaced or freed between storing and reading from the buffer.
I think trying to garbage-collect resources is more trouble than it's worth, and it doesn't make any sense to begin with. Data structures and resources are different enough in nature that they shouldn't be lumped together.

Also, you could turn resources into its own type and allow arithmetic on them. C and C++ does this with pointers already. GML could be extended, e.g. by defining iterators or just exposing the resource list (internally!) so maths can be done on a list index directly. So sprite_index++ would, rather than incrementing an abstract object directly, ask for its order in the resource list and return the next object.
 
I think trying to garbage-collect resources is more trouble than it's worth, and it doesn't make any sense to begin with. Data structures and resources are different enough in nature that they shouldn't be lumped together.
Well I I'm with you on that :D don't think resources should be garbage-collected at all... resources are like other engines' "ScriptableObjects"or even other engines' ...well... "Resources"! :p resources are just data stored in PC and cached into memory when in use and then removed from memory when not in use... but this "removing from memory" already happens.. when you leave a room it gets removed from memory (except if Persistent.. and I'm against persistent things maybe a game controller object and nothing else ;) ).
 

gnysek

Member
Ummm, I'm not sure that I said that resources will be garbage collected, I said that as they have on roadmap that at some point resources and ds_xxx structures will have own type so we can reference it (cause why only latter), and garbage collector (for ds_xxx) cannot be added before that change, it's not that simple to include it in this release. Maybe I used wrong order of words, so it looked that I wanted all to be garbage collected, but that was only about references over integers :) That's how it ends when I'm not a native English speaker and I want to use same phrase/word order like in my own language :p
 
The only thing I would like to know is if Q1 will be the dead line for the 2.3beta or 2.3final? because if Q1 is the deadline for 2.3beta then we could be looking at a middle March release, if Q1 is the deadline for 2.3 then the beta might come sooner..

Here goes my life’s story. I’m an almost 35 years old electronic engineer with a passion for gamedev since I was 12... and with the beginning of 2020 I’ve started dedicating more time to teaching GMS2 and I’m recording tutorials and courses (for explaining some basic and intermediate concepts). I’ve not posted them yet as I‘m afraid most of them will become obsolete as soon as 2.3 comes out, so right now I have my work life stalled. This is starting to have a major impact in my plannings. I do hope things get on track.
 
Last edited:

TsukaYuriko

🌠
Forum Staff
Moderator
There's no deadline for either of those, only a roadmap. The roadmap outlines the intention, not the actions. Which means: 2.3 beta was intended to be released in Q4 2019.
 

drandula

Member
Yes, that is true. It is just month's end sounds 'good time' to release new information, and we build up anticipation about hearing more of the 2.3. This anticipation at month's end can be regular thing, until we hear something ^^"
 

gnysek

Member
I don't believe they would say anything before open beta will be released. They probably feel that they are 99% done, but there's one or two small bugs which when they fixing, takes more and more time that they thought, so it's on a "can happen every hour" timeline.

Of course I have no knowledge about status of bugs, but knowing how they normally deal with releases, and how the chain looks (now it's longer cause of closed beta users, normally they are internally testing release for 4-5 days before giving anything to public), this can look like this:

-> make new closed beta release
-> give users at least 4-5 days to test it deeply, wait for bug reports, and then:
a) -> if there are critical bugs, fix them, make another build, QA checks that they are fixed, release closed beta again
b) -> if all is OK (nobody reporter critical bugs, or no bugs reported at all), release open beta (so after about one week of good build)

My prediction? 2nd week of March or later. But that's just blind guessing.
 
Last edited:

Xer0botXer0

Senpai
Wow, I feel like I need to buy GMS 2 now and get used to the new features before I get caught behind the wave where people are discussing the functionality instead of already in the know of it.
 
There's no deadline for either of those, only a roadmap. The roadmap outlines the intention, not the actions. Which means: 2.3 beta was intended to be released in Q4 2019.
I understand and you’re absolutely right on that point. But I do think a road map should be updated, that is the main purpose behind a roadmap.

https://canny.io/blog/product-roadmap-best-practices/

with this I’m not trying to teach anyone anything, YYG is a profissional team with a long history. The “future features not yet schedule” page got (silently) updated to remove the “lightweight objects will have destructor method” text. And yet the roadmap is left intact.

Are they still intending to release the 2.3beta in Q4 2019? :(

I’m not asking for 2.3 right away.. I’m asking YYG to keep us informed and updated.
 
Last edited:

gnysek

Member
I think that every day they looks to roadmap and says "one more day, maybe we will be sure what current dates are now, and we update it", and every day they need another one :p At least I hope it is that, cause previously they were updating roadmap every 2-3 months. In fact, they updated it last time probably just before when first closed beta should start (not sure if it was on time or not).
 
Last edited:

Henry00

Member
Imagine if they went with a syntax like this:

GML:
struct CarEngine
{
    acceleration = 100;

    constructor(_x, _y, _fuel)
    {
        cylinders = ds_list_create();
        x = _x;
        y = _y;
        fuel = _fuel / acceleration;
    }

    destructor()
    {
        ds_list_destroy(cylinders);
    }
  
    function explode()
    {
        var boom = 5 / 0;
    }
}

var engine = new CarEngine(20, 50, 1.0);
engine.explode();
delete engine;
It would prevent any magic function names like "delete" or "destroy" or "__delete". It makes constructors obvious to readers (unlike the "new" call on any function). And you could even not have any constructor.
 
Last edited:
Imagine if they went with a syntax like this:

GML:
struct CarEngine
{
    acceleration = 100;

    constructor(_x, _y, _fuel)
    {
        cylinders = ds_list_create();
        x = _x;
        y = _y;
        fuel = _fuel / acceleration;
    }

    destructor()
    {
        ds_list_destroy(cylinders);
    }
 
    function explode()
    {
        var boom = 5 / 0;
    }
}

var engine = new CarEngine(20, 50, 1.0);
engine.explode();
delete engine;
It would prevent any magic function names like "delete" or "destroy" or "__delete". It makes constructors obvious to readers (unlike the "new" call on any function). And you could even not have any constructor.
I'm not against any kind of implementation :) when I suggested "__delete" the idea was to avoid a new reserved keyword altogether, the struct part might be the way they'll do it.
The construct and destruct thing I don't believe they will do it like that... regarding destructors in general something tells me there will be no destructors at all (sadly).
The decisions they take now they will have to carry them for the rest of the GMS2 life... it would be very bad to change syntax half the way through.
 

gnysek

Member
Yeah, I like the example where it's named struct rather than function. But if they chosen function, for pseudo-class - no problem.

Probably, as they wanted to introduce Lightweight Objects (LWO, but finally they don't use that name), they wanted to keep them so light, that there's no build-in magical methods. But it might be hard to deal with them without destructors (as construtor is just the whole definition for now). Maybe it won't be a big problem to add it during open beta, but for sure lot of people will report that there's no way to unset data structures in structs, and some kind of solution should be added.

What with that unusual syntax (just came into my mind, I never saw any language to use it) ? that would still allow you to use any name for functions inside, and won't reserve any "magic" methods? it reminds try/catch a little. Completely crazy idea, but I started to like it in some way...
GML:
function myStruct() constructor {
  a = ds_map_create();
  b = 5;
  c = function() { return 7; }
} destructor {
  ds_map_destroy(a);
}
 

Nux

Member
From my understanding, there will be no destructors because it would cause compatibility issues with HTML5 (which I believe uses JavaScript).
(JavaScript also does not have destructors!!)

Having delete call a built-in "method" of the struct would be cool.

JavaScript:
function A() {
    var is_alive = true;
    show_debug_message("A has been created");
    // destructor
    destroy = function() {
        if (is_alive) {
            show_debug_message("A has been deleted");
            is_alive = false;
        } else {
            throw "cannot delete A twice";
        }
    };
}

var a = new A();
delete a; // basically the same as doing `a.destroy();`
I suppose you could keep track of whether a struct is "dead" so you don't accidentally double free a data structure it contains. Still not as great as an actual destructor, but it would be better than nothing.
 
Last edited:

Cpaz

Member
From my understanding, there will be no destructors because it would cause compatibility issues with HTML5 (which I believe uses JavaScript).
(JavaScript also does not have destructors!!)
I mean, what would be the point of adding garbage collection if they were going to add destructors anyway?
They want us to handle the likes of data structures and the like. Why stop there?

I dunno. I guess I'm not again the idea of destructors, but it seems redundant given the scope of everything else that's being added.
Or course, there are also the possible compatibility issues from something that *seems* non-standard. Especially since they've made it clear they're basing GML on javascript. Which, as you mentioned, doesn't use destructors and has garbage collection instead.
 

Nux

Member
what would be the point
Basically, for any sort dynamic resource. If you create a ds_list inside of a struct and don't destroy that list, it sicks around!

If all resources (objects, data structures, vertex buffers, etc.) were also garbage collected, yeah, it wouldn't a problem. But because they are not and we have to manage that memory ourselves, any sort of dynamic resource inside of a struct becomes a (potential) memory leak.

So by having delete be syntactic sugar for calling some method of the struct would be a nice quality of life improvement, otherwise quite a lot of things might end up being done the old GML way.
JavaScript:
function List() {
    items = ds_list_create();
}

function list_create() {
    return new List();
}

function list_destroy(_list) {
    ds_list_destroy(_list.items);
}

var my_list = list_create();
my_list.items[| 0] = 5;
list_destroy(my_list);
...which i don't think looks particularly nice compared to my previous example
 
Last edited:
I mean, what would be the point of adding garbage collection if they were going to add destructors anyway?
They want us to handle the likes of data structures and the like. Why stop there?

I dunno. I guess I'm not again the idea of destructors, but it seems redundant given the scope of everything else that's being added.
Or course, there are also the possible compatibility issues from something that *seems* non-standard. Especially since they've made it clear they're basing GML on javascript. Which, as you mentioned, doesn't use destructors and has garbage collection instead.
A destructor it's "similar" to a function inside an instance... that is called upon destruction.
so even if the struct (lightweight) instance is caught by the garbage collector its destructor would still get called.
It is not a substitution... both concepts can coexist.
Even though everyone until now only talked of destructors as a way of destroying data structures (ds_list, ds_grid, _ds_map...) living inside structs destructors can be used for a lot of things imagine you want for a method to be called when an objects gets destroyed

for example:
Code:
struct a()
{
     destroy = function() {
          show_debug_message("This struct was destroyed right now");
     }
}
every time an instance of that struct gets destroyed you are notified with a message (this can be useful for async activity.)

of course if we were to use ds_lists inside our struct being able to destroy it automatically would be perfect.

specially because right now data structures are not garbage collected... even though they will eventually do it (they plan to).

In resume what I wanted to say is that the destructor is not exclusively to destroying data structures.
 

Yal

🐧 *penguin noises*
GMC Elder
The Cleanup Event is essentially a destructor, the workaround if you need a destructor for something is to use a normal instance instead of an LWO / struct. I.e. instead of having a LWO manage your data structures, have an actual object do it, and keep struct contents being first-class citizen data types. It'll have worse performance, but more power (since you can use all the other events too if you want) so I don't see anything seriously wrong with this approach, even if proper RAII and arbitrarily complex data objects would've been nice.
 
The Cleanup Event is essentially a destructor, the workaround if you need a destructor for something is to use a normal instance instead of an LWO / struct. I.e. instead of having a LWO manage your data structures, have an actual object do it, and keep struct contents being first-class citizen data types. It'll have worse performance, but more power (since you can use all the other events too if you want) so I don't see anything seriously wrong with this approach, even if proper RAII and arbitrarily complex data objects would've been nice.
well the destructor idea was more in the spirit: "once we are already doing changes to GML, we could make things so they can be the as flexible and powerful as possible”
 
Last edited:

Miradur

Member
Patch 2.3 brings very big changes, so 6-8 weeks for a beta is still a very optimistic estimate. So I wouldn't expect a release before the end of April, but nice to see you dreaming.

Miradur
 
Patch 2.3 brings very big changes, so 6-8 weeks for a beta is still a very optimistic estimate. So I wouldn't expect a release before the end of April, but nice to see you dreaming.

Miradur
really end of April? I though we would see something in Q1.. at least a blog post.
 

TsukaYuriko

🌠
Forum Staff
Moderator
... and I'd like to once again remind everyone to please not guess anything (at least not publicly) and stick to the official facts, specifically to avoid it from confusing anyone that might interpret it as official... ;)
 

zbox

Member
GMC Elder
Can't wait for these updates. I've been doing a lot of JS programming lately and I sorely miss a lot of features that exist there!
 

gnysek

Member
Patch 2.3 brings very big changes, so 6-8 weeks for a beta is still a very optimistic estimate. So I wouldn't expect a release before the end of April, but nice to see you dreaming.

Miradur
I understand you talk about stable release ? Yeah, seems that it won't be before that date, after open beta starts they will for sure release at lest 1-2 updates to it, before it goes stable, and I won't expect it to be more often than every two weeks (2-3 days before people will report important bugs, 2-5 days to fix them, 2-3 days to test (with regression) everything again before release). But I still believe in open beta in 2-3 weeks from now.
 
Status
Not open for further replies.
Top