I think I have made a topic about this before, but I can't remember, so here it goes again, with some new insights.
As we all know in GM every ID for resources (LGM like sprites, background or runtime like ds_grid) is an integer. I always lowed this in GM, because it makes learning A LOT easier, as in C++ this usually involves pointers or references. But this makes code messy, as the engine doesn't know if the number "5" gives is an ID for sprite or a background. Here are some suggestions:
1) I previously suggested we just use classes (both return and pass to functions), as the user wouldn't know any better. He might be confused why "sprite_id*5" doesn't work, but that shouldn't work in any case. But it does mean problems with variables. By default every variable is a "variant", which means "variant" would have to cast to "Sprite" and "Background" and so on. I don't think that is possible, as it might only cast to "*Sprite" at best, and that would be required for this to work:
sprite_id = spr_some_guy;
We should pass references anyway, as I don't want to copy data in this instance.
2) Create a typedef which basically wraps integers. This seems like the best option and in my ultimate wisdom I didn't come up with it before. Basically we would have a type define as "Sprite_ID" and it would basically be an integer in every shape or form. The only difference is that if I pass a number 5 of type "Sprite_ID", then I know it's a sprite ID, not something else. The problem here is that we still need to cast variant to these types. Like this:
a = 5; //Here variant of type variant with value 5
a = spr_some_guy; //Here the variant needs to be cast, which I don't know if is even possible taking into account the POD nature
Also, this would mean we ALWAYS would have to use sprite name or the ID returned by sprite_add, to reference this sprite. This means we couldn't just load an integer from a file, and then use it as an ID. But the user shouldn't be doing that anyway, as he cannot know which ID the sprite will be assigned to. So I think we are okay in this regard. Slightly break GM compatibility, but greatly increases the future prospects we could have. Like we could replace draw_sprite, draw_background and draw_surface with one function - draw_image. And we could even allow draw_sprite's image frame argument to be supported via an overload.
3) Another way which would only partly fix this, is to have a unified ID vector. Like all sprites, backgrounds, rooms, instances etc. would use the same map or vector. This would mean every ID would be 100% unique, and thus identifiable with a certain kind of resource. But this greatly reduces the maximum of amount of resources possible (maximum integer can hold, which might not be enough if they include all instance of all rooms and even all tiles).
But I don't really suggest totally getting rid of all those functions. I think they can stay for the time being as they are required for GM compatibility, and we are quite used to them. What I actually need this functionality for is new stuff, especially extensions. Like I am in process of making a GUI extension (something on the lines mentioned in the wiki here:
http://enigma-dev.org/docs/Wiki/GUI_Functions) and I want to support these two case:
button_set_image(button,spr_button1);
button_set_image_hover(button,bg_button1);
Instead of:
button_set_image_sprite(button,spr_button1);
button_set_image_hover_background(button,bg_button1);
And the second case is with my own classes:
button_set_parent(button, window1);
window_set_parent(window1, window2);
Instead of bazillion variants like this:
button_set_parent_window(button, window1);
window_set_parent_window(window1, window2);
So basically I want the ID returned by functions like button_create(), not to be an integer without any type information, but identifiable as an instance of a class.
One way to fix this would be to ask users to code in C++. So they could in fact write:
Button button1 = button_create();
And then use "button1" everywhere as it's a C++ class. But I don't want that. I want the user to be able, to write:
button1 = button_create();
In my case maybe the third option could work, as I basically would have a GUI_MAP having all the GUI elements which would mean that every one will have a unique ID. But I wouldn't be able to use this for other resources like sprites or backgrounds.
So this topic is mostly addressed to Josh, as he deals with EDL. How would you propose to fix this?