77 replies to this topic

[Nocturne]

I honestly don´t mind either way... I can see how changing it could potentially improve GM greatly, but I can also see how it could confuse new users/beginners.

[gnysek]

It's good idea, but it can be hard to differ instances and objects from data structures with this syntax. Maybe better will be:

mylist = ds_list_create();
mylist->insert(1, myvalue);
mylist->destroy();

I'm using in my games ds_queues for dialogs, and ds_maps to define list of sprites, where as values there are another ds_maps, with keys like transparency, x,y, precise collision etc., and then I can write ResourceLoad('name') in GML which loads for me sprites from disk. Also whole world is saved on data structures - room is divided into zones, and when you changing them one zone is deleted, and another one is loaded from data in ds_maps - so it's veeeery boring of writing whole ds_* fuction names - for me you've got again VERY GOOD IDEA.

I think that begginers have problems with structures even now, so after change it cannot became harder, but only the same or for some people easier.

Edited by gnysek, 25 January 2011 - 09:20 AM.

[TheSnidr]

Wouldn't that be even more confusing?
I don't like this idea - probably because I'm so used to the handles, but also because I think new people would have a hard time understanding the difference between objects and datastructures. When looking at a piece of code, wouldn't it be hard to seperate the two?

I might come up with better arguments later.

[Revel]

I love the idea. Using handles alone make code very messy in my opinion and was a major drawback of using GM. I fully support the idea of using objects instead of handles.

If users could define their own "objects" (not game objects, but structures like C++), then GM would become extremely powerful. Especially if you added pointers then I would consider using GM again



But as gnysek said:

it can be hard to differ instances and objects from data structures wit this syntax.

[sabriath]

Here's a problem I see so far:

myds = ds_list_create();
mydscopy = myds;

The old way simply copied the identifier, so any change to "myds" would also change "mydscopy" by reference. In this situation of collections similar to other languages, how would this come across? Would it simply be moving the structure's pointer over to a new variable and maintain the reference like before, or will we lose this feature to a more by-value one?

This seems a bit of a weird question, until you reach a point like this:

ds_list_destroy(myds);

ds_list_add(mydscopy, 1);

Normally that would cause an error because "mydscopy" no longer exists as a data-structure, but if you make it pointer-bound, then you have a problem if you make it by-reference equality as before. You can circumvent this with pointer checking, but then you've done nothing different than what GM has already done before (by making a check into the list of data-structure values to get the actual point to the data). However, if you make it by-value, then everyone who has learned to program with the by-ref mindset will have to redo their work.

Tough call. I'm all for the change, makes the code look nicer, but as an added suggestion, there has to be by-val AND by-ref abilities. Maybe something like:

myds = ds_list_create();

mydscopy = myds; //by-reference copy
mydscopy2 = myds.copy(); //by-value copy

Also have an option in the compilation phase to turn off pointer checking for these structures (advanced settings obviously, but could speed up run-time if the game has already been debugged and ready for release).

[mcoot]

I think the idea is great. Having the ability to access things like data structures as objects would be very useful. I would argue it would actually be easier to learn than the current system. Which seems simpler: imagine a datastructure as an object with these properties, or trying to understand that it has a 'handle' - a value returned upon creation and stored in a variable for use.

it can be hard to differ instances and objects from data structures wit this syntax.

True, but that's kind of the point - that data structures would be treated like objects. In most other languages a data structure would be a class, and it would be nice to have some more OOP-like features in GM.

The only thing I would be worried about is compatibility. Would you leave the old method in for compatibility, or would you take it out and recommend games heavily laden with the old-style functions to keep using the old version for that game?

[gnysek]

I disagree with this. I think variable naming is key here. If I name an object list "myblockofcheese", then some might say it's your own fault for not naming things right. Also, improved intellisense would help alleviate the problem, as it would pop up with the functions/variables that object has. Structures should only be storage, while objects should have functions attached, in this way it's fairly simple to understand what they are. But feel free to give me an example of issues that might occur if the variable was named properly, and we had better intellisense working....?

Ok, and I forgot that objects are highlighted inside code editor, so this is also helpful with this syntax - instances have color, structures & references not.
So, if code completion will show me that variable 'abc' defined in Create Event is ds_* structure when I'm editing code inside Step Event in the same object, I'm buying it. If you also make that global variables will be in intellisense and you can execute events using objName.step_event(); - I can even marry you.

There is one problem with data structures... there is no garbage collector for them (since ds_*_create() only giving id of structure, not real reference, like for resources) - but it's look that you want to make a new type in GM 8.1 - strings, reals and collections - so maybe this will avoid the problem. Otherwise structures can be big trap for beginners because there is big risk that there will be memory leaks. This issue can also be hard to understand for begginners.

Edited by gnysek, 25 January 2011 - 10:01 AM.

[Derme]

I think it would be a great addition to GM, I have always found Data Collections confusing the current way they are written. They way Mike re-wrote it makes far more sense to me and something I would definitely like to see it changed.

The only concern I have is backwards compatibility, I don't really want all my code to break when I use the updated Game Maker.

[Robert3DG+]

Like Derme above me, I think it would be a nice addition if it was backwards compatible with the old codes, if possible.

[Schyler]

No. I really don't like it.

C++ is my main language, but recently I got back into GameMaker for some freelancing (and apparently GM is the tool of choice for Gamedev now); If you want complicated pointer management you can use a real language. GM is based around handles - the ability to view anything as a real value. Please don't break it - heck, I'm more worried that it'll break existing sources.

Edit:
Why can't you just make the compiler parse;

mylist->insert ( x, y, z )

as...

ds_list_insert ( mylist, x, y, z );

I can see this as being the best option, as it dosn't do anything whacky with changing the way everything works (stays handle-based). I assume then, that casting wouldn't be too bad an addition.

ds_list_create ( );
ds_list_create ( );
ds_list_create ( ); // the actual list being referenced

random_handle = 2;
(ds_list)random_handle.insert ( ... )

Edited by Schyler, 25 January 2011 - 10:33 AM.

[dadio]

I think for most current GM users, this change will be a non-event/go unnoticed.
(Most people wouldn't even know what you're taking about here...)

But for those who would use this, there'll be a division...
"code junkies/programmers" vs peeps like myself & TheSnidr & Schyler there who value the handles (kind of for "readability/differentiation" purposes) - I think this is the only real reason you're gonna get for "no" votes.

Whatever decisions are made, I hope that "simplicity" rides high on the priority list, as it's always been GMs strength. I'm all for new "additions", everyone loves "additions"...
but fundamental code structure "changes" are a different matter, (especially if they complicate the process for average GM users).

Compatibility would be my main concern (as mcoot & others touched on).
GM changes over the last few years have been relatively minor, but BIG changes are clearly in store with GM9.
There'll be *much* whine if there's no conversion tool from GM8 > GM9
(& it would be a huge pity if all the many tutorials/examples on the GMC were made obsolete when GM9 hits, as many current users rely heavily on these).

So, hopefully conversion is on the table (*or* at least that GM8 will remain viable & be fully supported & just as capable as GM9 for porting/publishing to new devices.)

[gnysek]

As it's only 8.x, it's more than sure that new versions will be compatible with previous ones from 8.x line, but no vice-versa. So, when you made something in 8.2 it will work in 8.3, but games from 8.3 will not open from 8.2 - and it's not (yet) the time to discus that GM9 will be backward compatible or not, so better leave it alone before flame war will start

[ragarnak]

While I can certainly understand this agrument, fear of change isn't a reason not to do it.

One of the best reasons not to do it is that what we currently have does work.

You seem to think that the new way of writing (because that seems to be all it will boil down to) is better than what we currently have. Can you explain why you think so ? What does that object-oriented way of denoting what should happen have over what we have now (apart from catering to C# programmers, which GM is not really aimed at) ?

This would allow us to do better syntax checking as we know what type the object is, it's not just a number that could actually be used by any number of collections.

As long as the resource-ID of that object works the same as for all the other resources (simple values, all starting at Zero) it will still create the same mess. I would still be able to use something like :

(3*2).insert( 1, myvalue );
bkg_floor.destroy();

... or you must mean you're going to introduce typed variables ....

Personally I would like that, as I can than ask a certain variable which resource it represents, and act accordingly. I could than even create overloaded script-functions.

The question is : does your company really want to introduce such complexity to GM ?


If you want to talk about collections / data-structures than why not look at existing problems with them and solve them before making such a, as far as I can see, cosmetic change ?

Which problems ? Well, I have a problem with not being able to check if the returned value from a data-structure function is not actually a content, but the default "Can't find anything" result (which, by the way, matches the first resource-ID of any of the created resources. Not handy).

Like iterating thru a ds_map structure. How do I detect the end ? And no, the size of that structure does not equal the number of returned elements (double-present keys are skipped) (problematic circumstances : a list with single retrievable entry and a list with a Zero as the key).

The addition of a user-definable default (like with registry-key retrieval) would certainly come in handy.

On the other hand, if you are going to introduce typed variables you could use something like the PHP method where you can also do a typed variable check ( "===" ), enabeling us to check if the returned result is actually retrieved content or a "no more data" result.

[True Valhalla]

I don't mind either way, as long as both methods are a possibility still ie. won't break my GM8.0 project.

[Smarty]

This would allow us to do better syntax checking as we know what type the object is, it's not just a number that could actually be used by any number of collections. It should mean (at some point), we could do error checking in the editor and flag up issues where you try and use the list object as an illegal parameter, or try and use it as a grid object etc. Improved intellisense could also prompt you with functions as you type, making it far easier to know what the variable is used for.

Only if the data structure is created in the current script. You couldn't error-check in the editor if the DS is created elsewhere - either in a different event of the same object, or in an alltogether different instance. Instances can create resources on behalf of other instances, after all.

In fact, since one instance could execute code within the context of another instance in this way:

with (other) mylist.add(value)

When setting up this script in the editor, there are too many unknowns - you don't know for sure if the other has a local collection called mylist, and even if it does, you don't know if add is a method of it. You can only know this at runtime, which means you gain very little by adding this in Game Maker's current syntax.

As it is, I'm unsure why you focus on data structures only when you suggest this approach. To make it work, and especially make it work at design time, it seems to me you're obligated to make Game Maker more object-oriented as a whole. This means that objects will have to become objects in the true sense, and that you build objects derived from Game Maker's default object model and add methods and properties (like aforementioned collections) to it. But that's far more of a change of course than this proposition suggests.

Edited by Smarty, 25 January 2011 - 11:54 AM.

[OpticalLiam]

Why just collections? Every resource in Game Maker should be like this. GML has always been overly verbose - "sprite_set_alpha_from_sprite(ind,spr)" should just be "spr.setAlpha(alpha)". I imagine some may argue that verbosity makes the language somehow easier for new programmers, but I really disagree that it's any easier than this alternative. Though, admittedly implementing this would be a radical change - you'd basically have to implement OOP and hence you'd have to deprecate a lot of functions. In any case, GML is simply a terrible language as it is. In my opinion, either get it up to date or throw it out and replace it with something like Python - because otherwise it will never be generally accepted as a 'legitimate' programming language these days.

Edited by OpticalLiam, 25 January 2011 - 12:06 PM.

[Schyler]

I was just wondering; would YoYo have the time to rewrite Intellisense? Because if you don't, I don't feel the need to continue down this path of discussion.

On a side note, how about we completely overhaul GML to have a collection based function system, rather than object collections themselves?

tile.translate ( ... )
background.create ( ... )
room.create ( ... )
room.resize ( ... ) // also possible;

rm_menu.resize ( ... )

object.create ( ... ) // in this context, object is a type that can be recognized already, so the following is possible
object.destroy ( ... )

obj_controller.create ( x, y ) // removes first argument, handle

self.destory ( ) // self is an (object != noone), so this becomes instance_destroy ( );

I don't think that lists should have this type of support though. There's no way to really tell when a list is created, unless you add data structures to the left-hand side of GameMaker (NOO!!).