77 replies to this topic

[ND4SPD]

Could confuse things and end up with naming conflicts.

Would the collections be local to a particular instance? Currently, you can create a list called item_list, say, and create another one in another object called item_list as well, and have no naming conflicts since they id of the list is in a local variable, where it can still be easily referenced from another instance. With this, however, you'd either end up with naming conflicts (if the collection is available to all instances) where you can't have more than one item_list (in the same way you couldn't have more than one obj_player), OR you'd have code such as obj_npc5.item_list.destroy()...

[Smarty]

Not true. Sure until the script defining the vartiable is actualyl written, intellisense won't know about it, but intellisense is project wide, so once it's written, it will become visible to other scripts, in other objects. This is what Visual Studio does, and it works pretty well, so I see no reason to do anything different.

I'm perfectly aware of how Visual Studio does it, but Visual Studio does is able to do it because it is tied to a strongly typed language. That's not what Game Maker is. Game Maker is very weakly typed, if typed at all. Take the keyword other, which I used in my example. It references the other instance in a collision. At design time, it can make no assumptions on what kind of object it is and what kind of scripts it has run or is going to run, or what object/instances have run on behalf of it. Intellisense is unable to backtrack through all the existing scripts in the hope to find out what it may contain. Don't dismiss that objection, because it goes to show you don't understand how Game Maker works.

[gnysek]

(..) Take the keyword other, which I used in my example. It references the other instance in a collision. (...)

Also, in with () construction, it refers to object instance from which it was called.

Edited by gnysek, 25 January 2011 - 02:13 PM.

[Smarty]

Don't dismiss that objection, because it goes to show you don't understand how Game Maker works.

On retrospect that came out a little more unfriendly than I intended it, for which I apologize.

[thatshelby]

I wouldn't mind it. I like it the way it is now, but this would be better practice for those learning lower level languages. I would love to see more genuine programming implemented into GML. Though, how would you do this in a with() loop if it acts as a variable?

with (object) {
  other.mylist.insert();
}

Of course this exact scenario would be pointless, but imagine there's a reason for it.


Would these structures be classed as global variables, or unique to each instance like the handle is now?

[Smarty]

Okay - well, to be honest I don't see much point in implementing this in version 8.1. I prefer the object-oriented notation you propose but there currently isn't much of a benefit other than a cosmetic improvement of the language.

In fact, it adds another suggestion of OOP to Game Maker that isn't carried through entirely in its design, and that ambiguous design doesn't make it all that clear to new users and OOP language users alike. I'd wait with it until YYG are ready to actually redesign the language and the engine to fit that syntax.

[quick12]

I don't think it's a good idea. If it ain't broke, don't fix it. I can see where it could help in some places, but ultimately, what we already have works. I think it would be better to leave it as it is. You have to specifically name a variable in order to remember what it is, lengthening the variable, and I prefer to keep my variables short and consise, to improve readability and programability. If I want to make an inventory, I call the variable "inventory". If I want to have more than one inventory for different characters, I use "char1_inventory". Those are as short as I can write them and still understand them. I would find keeping a note on every one to simply let me know what kind of data structure or particle system or surface the variable holds annoying. Trying to remember what every single one is would be no treat, either. Say you are hunting for a bug in the game programming. This would be the source of many problems for me, personally. In trade, Game Maker gains no functionality whatsoever. Sure, maybe code becomes a little cleaner, but programmers will understand their own code anyways. It just isn't of any use. I find using "handles" quite simple. Plus note that you'll have several identically named functions if you use this, which also causes confusion. "mylist.destroy()" and "myparticle.destroy()", for example.

As I said, if it ain't broke, don't fix it. That's my two cents on this topic. Note that it doesn't relate to any of the above conversation.

Edited by quick12, 25 January 2011 - 03:57 PM.

[thatshelby]

I don't think it's a good idea. If it ain't broke, don't fix it. I can see where it could help in some places, but ultimately, what we already have works. I think it would be better to leave it as it is. You have to specifically name a variable in order to remember what it is, lengthening the variable, and I prefer to keep my variables short and consise, to improve readability and programability. If I want to make an inventory, I call the variable "inventory". If I want to have more than one inventory for different characters, I use "char1_inventory". Those are as short as I can write them and still understand them. I would find keeping a note on every one to simply let me know what kind of data structure or particle system or surface the variable holds annoying. Trying to remember what every single one is would be no treat, either. Say you are hunting for a bug in the game programming. This would be the source of many problems for me, personally. In trade, Game Maker gains no functionality whatsoever. Sure, maybe code becomes a little cleaner, but programmers will understand their own code anyways. It just isn't of any use. I find using "handles" quite simple. Plus note that you'll have several identically named functions if you use this, which also causes confusion. "mylist.destroy()" and "myparticle.destroy()", for example.

As I said, if it ain't broke, don't fix it. That's my two cents on this topic. Note that it doesn't relate to any of the above conversation.

destroy() would be a global function, that is, mylist.destroy() and myparticlesys.destroy() would be two of the same things, except functioning differently. It's kind of like instance_destroy(). Instead of having a function for destroying an instance of every object, this function works with everything.


Also, you can't use that kind of mentality for everything, especially not software, which is a competitive world of business. New features are practically mandatory. No program can ever be finished, unless it does everything known to mankind.


I voted the "NO!!!!" option, but I've warmed up to the idea. I like it a lot now. It just makes sense.

Edited by Theophilus, 25 January 2011 - 04:05 PM.

[Medusar]

I really like this. I don't think this will make things much more difficult for beginners. I'm not a beginner anymore, but to me mylist.destroy() is more intuitive than ds_list_destroy(mylist). I don't really see how this could be more difficult for beginners. The improved type checking will also help preventing some beginner mistakes, such as using sprite and background indices instead of texture indices. Code would become a lot cleaner, too.

Would it - in the future - be possible to add your own "object types"? So say I wanted to create my own data structure, would I be able to create an object with member functions for that? And how about DLLs returning objects?

[quick12]

*snip*

destroy() would be a global function, that is, mylist.destroy() and myparticlesys.destroy() would be two of the same things, except functioning differently. It's kind of like instance_destroy(). Instead of having a function for destroying an instance of every object, this function works with everything.

What about ds_list_add(id,value) and ds_map_add(id,key,value)? Unless I am mistaken, can't use the same function for those.

Also, you can't use that kind of mentality for everything, especially not software, which is a competitive world of business. New features are practically mandatory. No program can ever be finished, unless it does everything known to mankind.

I agree, but I believe that mentality is valid here. There's nothing wrong with the current way these things are handled. It's not broke. This is fixing it. Game Maker is gaining no additional functionality by changing how lists and particles systems and whatnot are handled. It is a reformat.

I voted the "NO!!!!" option, but I've warmed up to the idea. I like it a lot now. It just makes sense.

And I may change my mind at the end of the day too. But I'll have to be convinced to, as what I am saying makes sense to me, even if it seems a bad idea to you. It's simply a matter of view and opinion.

Edited by quick12, 25 January 2011 - 04:34 PM.

[ragarnak]

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

Not necessarily. Just because a handle isn't a pointer, doesn't mean it starts at 0, and counts up. I'm very much in favour of almost random numbers as it stops the madness of arithmetic on handles.

I can't say that I have seen many posts about problems related to such arithmetic on handles (resource-IDs). Less than a handfull in all the years I've now been a member here. You would be solving a pretty-much non-existing problem ...

Though some people will (try to) use the actual resource-ID value instead of the resources "name" it will most allways bite them in the behind when they do, teaching them not to do it again. I've not seen many posts in regard to this either ...

Randomization sounds great, until you realize that not being able to reproduce a certain error is included in it. Personally I would rather have a problem that I can reproduce than having the uncertainty of if the error I once had is still lurking somewhere, hidden by such randomization.

Maybe a simple but quite effective solution would be to number all resources sequentially, with no resource-ID used more than once. Add a bit of "garbage collection" on them when saving, loading or starting a game, and problems like using the wrong resource or "arithmetic on handles" would not really be posible anymore (it would almost directly bite you in the behind). It would also introduce the possibility to ask for some information on a certain resource-ID and get a name as well as a type back.

Ofcourse, a bit of randomization on the re-sequentialized resource-IDs would still be a possibility (as long as no duplicates can exist).

[thatshelby]

What about ds_list_add(id,value) and ds_map_add(id,key,value)? Unless I am mistaken, can't use the same function for those.

Good point...

I agree, but I believe that mentality is valid here. There's nothing wrong with the current way these things are handled. It's not broke. This is fixing it. Game Maker is gaining no additional functionality by changing how lists and particles systems and whatnot are handled. It is a reformat.

Actually, it is. This would be much faster, as internally, GM doesn't have to dig for the handle. Also, it would make for much more organized code. Game Maker is not gaining anything. The end user is.

EDIT: This might even allow for saving/loading of data structures with game_save/game_load, but I would still use the ds_*_write(...).

Edited by Theophilus, 25 January 2011 - 04:39 PM.

[ragarnak]

What about ds_list_add(id,value) and ds_map_add(id,key,value)? Unless I am mistaken, can't use the same function for those.

Several programming-languages have no problem with this.

Ofcourse, those a strong-typed languages, where the compiler can determine the function that should be called (even in the same OO object) by comparing the provided arguments types to that of what the same-named functions expect.

Alas, because of weak typing GM uses that won't really be possible here.

[gnysek]

What about ds_list_add(id,value) and ds_map_add(id,key,value)? Unless I am mistaken, can't use the same function for those.

The same you know now that 'id' once is list and once map, the same you can write id.add(value) and id.add(key,value) - id is only a reference to real collection. Both ways (current, and proposed) you need to remember which type of data structure you are you reffering. That's why there will be also Intellisense - and it also will help even when only ds_*_functions will be available in next versions. The truth is that only difference is that you using some less character in code editor, which saves you some seconds, but everything is working the same way.

[Medusar]

What about ds_list_add(id,value) and ds_map_add(id,key,value)? Unless I am mistaken, can't use the same function for those.

mylist.add(value) and mymap.add(key, value) would be member functions to list and map objects, respectively. This whole proposal implies that GM becomes more strongly typed, which means that GM would know that the mylist variable holds a ds_list and that mymap holds a ds_map. This should be no problem, though it will break some old code bases as it does quite fundamentally change how GM works.

[thatshelby]

So this means, if this were to be implemented with everything that uses a handle,

bgtex.background_get_texture(background)

We can check if a texture is a background or sprite. Or surface, which is not natively supported with GM. You must use surfacefix.dll.

But what about DLLs that return handles?

[BlueMoonProductions]

If you add this, will old methods(using handles) be compitable with GM8.1? If not, I suggest you don't add this to a 'small'(.1) version, but wait until a bigger one(9). I personally don't feel much for rewriting my entire game, simply because handles are replaced by objects.

[Rusky]

I really think this is two separate issues: types and syntax.

You could update GM to use typed handles without breaking any code except for handle arithmetic, which is as ragarnak said not used often and a bad idea anyway. For collection this would not be the most useful of changes, but for things like textures vs. sprites it would be immensely helpful. I cannot stress enough that you can add strong handle typing without breaking code. The only difference the user would see is better error messages. I'm not sure about GM's internals, but a system like this might even be simpler or more efficient- variables would have a known-valid pointer rather than a double that has to be validated and looked up. Beyond that, it would make automatic garbage collection a possibility. No more ds_*_delete, things just get freed when it's impossible to reference them.

The changes in syntax are independent of the changes in how GM handles types. We already have that kind of syntax with objects (for variables, anyway), so extending it to methods would mostly be a matter of convenience. It would make things much less verbose, and would enable better intellisense in some situations. However, it could also make intellisense harder because variables can be created and have their type changed at runtime- suggestions could be both missing and wrong, depending on the context. I voted yes, but I'm not sure how I feel about the syntax changes with GML's current type system. However, you could certainly add overloading and/or default arguments to help remove some of the verbosity in the meantime.