Jump to content


Photo

Collections...


  • This topic is locked This topic is locked
76 replies to this topic

Poll: At a glance... (117 member(s) have cast votes)

Do you like this concept?

You cannot see the results of the poll until you have voted. Please login and cast your vote to see the results of this poll.
Vote

#1 Mike.Dailly

Mike.Dailly

    Evil YoYo Games Employee

  • Administrators
  • 4741 posts
  • Version:GM:Studio

Posted 25 January 2011 - 08:35 AM

Okay, a slightly more contentious one. I know some will hate this idea, and we are still debating it internally, but depending on feekback, it might open up some other concepts, so here we go....

Currently when you create a collection, you get back a handle to this object. I'm not a fan of this, I think it's confusing, and a messy. I would much rather return the collection as an object. In this way you could access functions/features directly as you would in an instance. For example, currently you do something like this...

mylist = ds_list_create();
ds_list_insert(mylist, 1, myvalue );
ds_list_destroy( mylist );

I don't like this. I think even beginners know the concept of an object because they have to deal with instances all the time anyway. So why not....

mylist = ds_list_create();
mylist.insert( 1, myvalue );
mylist.destroy();

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.

However... some people might think this is a step too far for them or beginners.

What do you think? Obviously is people like this, it could open up a WHOLE new approach for GML, so have a good long think about it first....
  • 0

#2 Nocturne

Nocturne

    Nocturne Games

  • Administrators
  • 24504 posts
  • Version:GM:Studio

Posted 25 January 2011 - 08:44 AM

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.
  • 0

lz6lxdC.pngd7ZQQ3F.gifFlvJzyf.png

40799.png


#3 gnysek

gnysek

    GMC Member

  • GMC Member
  • 583 posts
  • Version:GM:Studio

Posted 25 January 2011 - 08:46 AM

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.

  • 0

Previously game developer at YoYoGames, Currently PHP developer in DB-Team
Programming and working with: GML/C#/PHP/JS/MySql/CSS/HTML

Follow 
@GameMakerUpdate to get info about latest versions of GM when they are released: https://twitter.com/GameMakerUpdate

(it's managed by bot, not by human, remember)


#4 TheSnidr

TheSnidr

    Heavy metal viking dentist

  • Global Moderators
  • 3199 posts
  • Version:GM:Studio

Posted 25 January 2011 - 09:08 AM

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.
  • 0

#5 Revel

Revel

    ɹǝqɯǝɯ ɔɯƃ

  • GMC Member
  • 4935 posts
  • Version:GM8

Posted 25 January 2011 - 09:09 AM

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 :rolleyes:



But as gnysek said:

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


  • 0

#6 sabriath

sabriath

    12013

  • GMC Member
  • 3197 posts

Posted 25 January 2011 - 09:32 AM

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).
  • 0

Tutorials of Interest:
* Multiplayer: mine or True Valhalla's

Projects:
* Net39
* My 39dll scripts
* My 39dll lib
* Multiplayer Engine
* Artificial Chemistry

Posted Image

#7 Mike.Dailly

Mike.Dailly

    Evil YoYo Games Employee

  • Administrators
  • 4741 posts
  • Version:GM:Studio

Posted 25 January 2011 - 09:34 AM

I don't like this idea - probably because I'm so used to the handles....

While I can certainly understand this agrument, fear of change isn't a reason not to do it. Everyone gets comfortable in their coding style and are apprehensive when new things come along to change what they spent time learning. We all do that. But advancement will only come if me make that extra effort, and try to make things better. So unless theres a more solid reason, I'm still not yet convinced.

Especially if you added pointers then I would consider using GM again

Never. Pointers are nasty, horrible and a nessisary evil of other languages that don't have any alternative. :)

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

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....?

Normally that would cause an error because "mydscopy" no longer exists as a data-structure, but if you make it pointer-bound...

I never said it would be pointer bound. :)
It may well still be a "handle" the engine uses to de-refrence the object, but to the user it looks more like an object. This means when you dispose of it and then use it again, you should get the same error as before. Long term, an "optimised" build where handles really are pointers may one day appear, but.... you would accept the issues this brings with it. I'm not a massive fan of that, and as far as the user goes, theres no reason for you to ever know.
  • 0

#8 mcoot

mcoot

    GMC Member

  • New Member
  • 387 posts

Posted 25 January 2011 - 09:34 AM

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?
  • 0

Ultimate Healthbars - Easy healthbars in shapes from circular to sine wave

The obligatory (anti)religious signature message: Irreducible complexity is a stupid argument - what seems absurd is not a valid guide in science


#9 gnysek

gnysek

    GMC Member

  • GMC Member
  • 583 posts
  • Version:GM:Studio

Posted 25 January 2011 - 09:53 AM

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.

  • 0

Previously game developer at YoYoGames, Currently PHP developer in DB-Team
Programming and working with: GML/C#/PHP/JS/MySql/CSS/HTML

Follow 
@GameMakerUpdate to get info about latest versions of GM when they are released: https://twitter.com/GameMakerUpdate

(it's managed by bot, not by human, remember)


#10 Derme

Derme

    Time for a break.

  • GMC Member
  • 487 posts
  • Version:GM:Studio

Posted 25 January 2011 - 10:24 AM

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.
  • 1
TwitterBanner_zpsf5eaf370.pngSignBanner_zps6e538aa2.pngjust21_promo_graphic_zps785b873f.png

#11 Schyler

Schyler

    Noskcirderf Derf

  • GMC Member
  • 2680 posts
  • Version:GM:Studio

Posted 25 January 2011 - 10:28 AM

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.

  • 2

#12 dadio

dadio

    I miss my cupcake

  • YoYo Games Staff
  • 2254 posts
  • Version:GM:Studio

Posted 25 January 2011 - 10:41 AM

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.)
  • 0

2a7ubuv.jpg


#13 Mike.Dailly

Mike.Dailly

    Evil YoYo Games Employee

  • Administrators
  • 4741 posts
  • Version:GM:Studio

Posted 25 January 2011 - 10:48 AM

Why can't you just make the compiler parse...blah

Actually, this is more or less the way I think it would work. This isn't to say they would be interchangeable, just that the value returned would still be a handle of sorts, i.e. not a pointer, but the compiler would understand it's an object, and not just a number.

I wouldn't allow casting. You only need that when dealing with pointers, and if you assign a variable like this...
 List2 = List;
Then as before, your simply taking a reference, and not taking a full copy, and it would "become" an object to be used as normal.

From a user point of view, the "value" being returned will look much the same, but internally we'll know it's an object, and as such can be accessed as described. I want to avoid "->" if I can, because that could get confusing with folk that use pointers in other langauges, and they might assume they can simply add something to the value they got back to get to the next one, and this won't be the case.

Internally, it's still a handle to the object. Only the syntax would have 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.

As to keeping the old ones, yes. For a while at least we'd have both, thereby giving you time to swap over. But at somepoint one ofthem would have to go. While I fully accept that it'll break possibly lots of code, it should be a simple change which given both being active for a while, should be simple for everyone to swap over to. Past experiance however shows that people will only actually make the change when they really REALLY have to, i.e. when the old one is no longer there. <_<
  • 0

#14 gnysek

gnysek

    GMC Member

  • GMC Member
  • 583 posts
  • Version:GM:Studio

Posted 25 January 2011 - 10:48 AM

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 ;)
  • 0

Previously game developer at YoYoGames, Currently PHP developer in DB-Team
Programming and working with: GML/C#/PHP/JS/MySql/CSS/HTML

Follow 
@GameMakerUpdate to get info about latest versions of GM when they are released: https://twitter.com/GameMakerUpdate

(it's managed by bot, not by human, remember)


#15 ragarnak

ragarnak

    GMC Member

  • GMC Elder
  • 19468 posts
  • Version:GM8

Posted 25 January 2011 - 11:07 AM

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.
  • 0

#16 True Valhalla

True Valhalla

    ಠ_ಠ

  • GMC Member
  • 5277 posts
  • Version:Unknown

Posted 25 January 2011 - 11:08 AM

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

book_forum.png


#17 Smarty

Smarty

    GMC Member

  • GMC Elder
  • 7479 posts
  • Version:GM:Studio

Posted 25 January 2011 - 11:54 AM

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.

  • 1

#18 OpticalLiam

OpticalLiam

    GMC Member

  • New Member
  • 782 posts

Posted 25 January 2011 - 11:57 AM

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.

  • 1

#19 Schyler

Schyler

    Noskcirderf Derf

  • GMC Member
  • 2680 posts
  • Version:GM:Studio

Posted 25 January 2011 - 12:16 PM

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!!).
  • 0

#20 ND4SPD

ND4SPD

    GMC Member

  • GMC Member
  • 2180 posts

Posted 25 January 2011 - 12:45 PM

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()...
  • 0

#21 Mike.Dailly

Mike.Dailly

    Evil YoYo Games Employee

  • Administrators
  • 4741 posts
  • Version:GM:Studio

Posted 25 January 2011 - 01:19 PM

As it is, I'm unsure why you focus on data structures only when you suggest this approach.

Why just collections? Every resource in Game Maker should be like this.

I'm only concentrating on these as it's a simple thing to discuss. But, if folk accept the syntax in general, then we can think about a larger discussion on how this could affect GML as a whole. But I don't want to get sidetracked into a "what if we changed GML" discussion. Thats a massive point, and I simply don't want to get into it just yet. So, please stay focused on this simple case.

Only if the data structure is created in the current script....blah

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.

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

I disagree with that. The very simple system we have means its very easy to use a handle from one collection in another, usually with horrible consequences. On top of this, collections aren't very nice internally, so do need rewritten. So while doing this... it's a good idea to see if it's implemented and presented in the best possible way.

(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. Those are bugs just waiting to happen.
  • 0

#22 Smarty

Smarty

    GMC Member

  • GMC Elder
  • 7479 posts
  • Version:GM:Studio

Posted 25 January 2011 - 01:51 PM

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.
  • 3

#23 gnysek

gnysek

    GMC Member

  • GMC Member
  • 583 posts
  • Version:GM:Studio

Posted 25 January 2011 - 02:12 PM

(..) 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.

  • 0

Previously game developer at YoYoGames, Currently PHP developer in DB-Team
Programming and working with: GML/C#/PHP/JS/MySql/CSS/HTML

Follow 
@GameMakerUpdate to get info about latest versions of GM when they are released: https://twitter.com/GameMakerUpdate

(it's managed by bot, not by human, remember)


#24 Smarty

Smarty

    GMC Member

  • GMC Elder
  • 7479 posts
  • Version:GM:Studio

Posted 25 January 2011 - 02:35 PM

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.
  • 1

#25 Mike.Dailly

Mike.Dailly

    Evil YoYo Games Employee

  • Administrators
  • 4741 posts
  • Version:GM:Studio

Posted 25 January 2011 - 02:39 PM

Yes, your right that a variable can switch type at anytime, and yes... that would mean we couldn't sense it correctly. This starts to bring in a discussion about "typing" data, but we'll ignore it for now and assume that "for the most part", intellisence could pick up the object and type, but it's easy to break if they reuse variables for multiple types (strings, objects, collections, values etc...). If you continually reuse a variable name, your asking for trouble, but I can see some cases where having it as an "object" handle, where the type of object changes would be very handy.

The with() statement doesn't matter, because we can change context inside that and pickup the correct object.

We'll need to discuss variables and inheret type at some point I guess, because it may well all hinge on that. Of course, even very early BASIC had this concept, with its ints, floats, and String$ so I dont think it too much of a leap - but not for discussion just yet.
  • 0

#26 thatshelby

thatshelby

    GMC Member

  • GMC Member
  • 3823 posts
  • Version:GM8

Posted 25 January 2011 - 03:23 PM

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?
  • 0

#27 Smarty

Smarty

    GMC Member

  • GMC Elder
  • 7479 posts
  • Version:GM:Studio

Posted 25 January 2011 - 03:24 PM

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.
  • 0

#28 quick12

quick12

    GMC Member

  • GMC Member
  • 120 posts
  • Version:GM8

Posted 25 January 2011 - 03:56 PM

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.

  • 1

#29 thatshelby

thatshelby

    GMC Member

  • GMC Member
  • 3823 posts
  • Version:GM8

Posted 25 January 2011 - 04:03 PM

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.

  • 0

#30 Medusar

Medusar

    GMC Member

  • GMC Member
  • 1228 posts
  • Version:GM:Studio

Posted 25 January 2011 - 04:26 PM

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?
  • 0

Posted Image

Q: Why do programmers always get Christmas and Halloween mixed up?
A: Because DEC 25 = OCT 31

#31 quick12

quick12

    GMC Member

  • GMC Member
  • 120 posts
  • Version:GM8

Posted 25 January 2011 - 04:34 PM


*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.

  • 0

#32 ragarnak

ragarnak

    GMC Member

  • GMC Elder
  • 19468 posts
  • Version:GM8

Posted 25 January 2011 - 04:35 PM

(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. :mellow:

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).
  • 0

#33 thatshelby

thatshelby

    GMC Member

  • GMC Member
  • 3823 posts
  • Version:GM8

Posted 25 January 2011 - 04:38 PM

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.

  • 0

#34 ragarnak

ragarnak

    GMC Member

  • GMC Elder
  • 19468 posts
  • Version:GM8

Posted 25 January 2011 - 04:43 PM

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.
  • 0

#35 gnysek

gnysek

    GMC Member

  • GMC Member
  • 583 posts
  • Version:GM:Studio

Posted 25 January 2011 - 04:50 PM

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.
  • 0

Previously game developer at YoYoGames, Currently PHP developer in DB-Team
Programming and working with: GML/C#/PHP/JS/MySql/CSS/HTML

Follow 
@GameMakerUpdate to get info about latest versions of GM when they are released: https://twitter.com/GameMakerUpdate

(it's managed by bot, not by human, remember)


#36 Medusar

Medusar

    GMC Member

  • GMC Member
  • 1228 posts
  • Version:GM:Studio

Posted 25 January 2011 - 04:51 PM

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.
  • 0

Posted Image

Q: Why do programmers always get Christmas and Halloween mixed up?
A: Because DEC 25 = OCT 31

#37 thatshelby

thatshelby

    GMC Member

  • GMC Member
  • 3823 posts
  • Version:GM8

Posted 25 January 2011 - 04:56 PM

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?
  • 0

#38 BlueMoonProductions

BlueMoonProductions

    BlueMoonProductions

  • GMC Member
  • 241 posts
  • Version:GM:Studio

Posted 25 January 2011 - 05:37 PM

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.
  • 1

#39 Rusky

Rusky

    GMC Member

  • GMC Member
  • 2492 posts
  • Version:Unknown

Posted 25 January 2011 - 06:22 PM

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.
  • 0

#40 Erik Leppen

Erik Leppen

    GMC Member

  • GMC Member
  • 2690 posts
  • Version:GM:Studio

Posted 25 January 2011 - 07:28 PM

I voted No because I think this will complicate GML without really adding much. Currently, GML is quite simple to learn because it has realatively few features. It's quite easy to understand how GML works. A list had an index, and the index is stored in a variable. To access the list, you need to have the index. To get the index, you must read the variable. The variable works just like any other variable. It's all very intuitive.

How's this done with the new system? I am not an expert on this, but I have the feeling that adding new syntactic features that don't really add much functionality-wise, might confuse GM users.

So, how would such a system work exactly? When using

mylist = ds_list_create();
mylist.insert( 1, myvalue );
mylist.destroy();
is mylist a local variable holding the list index? Which means that mylist is stored in some instance. So we can do
(other.mylist).insert(1, value)?
Also, can I store the list index in a(nother) variable? E.g. can I now say
var li;
li = choose(mylist1, mylist2)
li.insert(1, value)

What would show_debug_message(mylist) do? Can I store the list index in a variable? Also can several instances each have their own mylist (e.g. if I want every enemy instance contain a list of visited nodes)? Can I pass the variable to another instance, e.g. when an enemy wants to know if the enemy it collides with has visited node X)? Can I make a list whose index is global? And how would this be indicated? I'm guessing
(global.mylist).insert(1, myvalue)
How can I make my own script for lists? With the current setup I can make a ds_list_swap and have the list index as argument0 and I can then just do
//ds_list_swap(ind, pos1, pos2)
var temp;
temp = ds_list_find_value(argument0, argument1)
ds_list_replace(argument0, argument1, ds_list_find_value(argument0, argument2))
ds_list_replace(argument0, argument2, temp)
With the proposed list syntax, how would such a swap script be defined in GML, in such a way that we can use mylist.swap(pos1, pos2)? Could you give an example of that?

Finally, can we have something like
mylist.type
to find out whether it's a list or a stack, instance, resource, particle type, etc.? E.g. by using
if mylist.type = ds_list
{
  //code to execute if mylist is a list
}
where ds_list is a built-in constant?

Edit: also, what about an existence check? You cannot do
mylist.exists()
because if mylist doesn't exist, I would expect an unknown variable error. If this error won't appear, this would be an inconsistency in the system, because right now it's a rule in GML that everything to the left of a dot, has to be defined.

As you can see, this whole concept raises a lot of questions I'm really not sure about. And that while the current system seems to work fine for me (or at least not worse than the proposed system).

Edited by Erik Leppen, 25 January 2011 - 07:33 PM.

  • 0

promo_briquidmini_500x150.png


#41 ragarnak

ragarnak

    GMC Member

  • GMC Elder
  • 19468 posts
  • Version:GM8

Posted 25 January 2011 - 07:45 PM

Actually, it is. This would be much faster, as internally, GM doesn't have to dig for the handle.

Only if you force those structures only to be global ones, breaking lots of current functionality.

You see, if you would want to keep being able to store the data-structures handle somewhere (into an instance or script-local variable, into another data-structure or supply to or return from a script) you would have access to that very handle, and thus to be able to access it directly (if supplied to a DLL).

Although I would welcome such a direct-access possibility I don't think that is what YoYoGames wants (otherwise they would have done so long ago ...)

You cannot do

mylist.exists()
because if mylist doesn't exist, I would expect an unknown variable error.

Probably just as in other languages, or pretty-much the same as we currently do with instances : check if the contents of that "mylist" variable is valid. Probably something like
if mylist>=0 {
  mylist.something()
}

Edited by ragarnak, 25 January 2011 - 07:51 PM.

  • 0

#42 Erik Leppen

Erik Leppen

    GMC Member

  • GMC Member
  • 2690 posts
  • Version:GM:Studio

Posted 25 January 2011 - 08:12 PM

Probably something like

if mylist>=0 {
  mylist.something()
}

Problem: this ">= 0" business is exactly the arithmetic I thought is frowned upon. At least I don't like it. As a programmer I shouldn't have to know that these indices are nonnegative integers. For instances I never use >= 0, I usually use instance_exists(...) because that's what I mean.
  • 0

promo_briquidmini_500x150.png


#43 silentworks

silentworks

    GMC Member

  • GMC Member
  • 579 posts
  • Version:Unknown

Posted 25 January 2011 - 08:32 PM

Is there any chance, that we can add our own methods to collections (objects)?
  • 0

#44 IceMetalPunk

IceMetalPunk

    InfiniteIMPerfection

  • GMC Elder
  • 9603 posts
  • Version:GM:Studio

Posted 25 January 2011 - 08:38 PM

To be honest, I don't really care about the syntax. What I do care about, however, is GM being able to differentiate between a data structure and a real value. That would make it much easier when returning collections from scripts, since the returned value couldn't be used in any way except that which the script intended--as a collection.

I'm assuming this would also mean comparisons between real values and collections would fail (as they should)? That's another plus. When writing lots of code, it sometimes happens that people will do things like this:

var1=2;
/*
.
.
.
Lots and lots of code, time, and testing later...
.
.
.
*/

var2=ds_list_create();
/*
.
.
.
Even more code, time, and testing later...
.
.
.
*/

if (var1==var2) { show_message("Values are the same!"); }

When these things are overlooked, you wind up with code that doesn't work as expected, but also doesn't throw any errors. It makes it very hard to debug when it's in the middle of lots of code.

Of course, if collections are recognized as a separate data type, the comparison would correctly fail and generate a nice error pointing to the line where the invalid comparison occurred.

So, all in all, I'm in favor of this more for functional reasons than syntactic ones.

-IMP ;) :)

*EDIT*


Probably something like

if mylist>=0 {
  mylist.something()
}

Problem: this ">= 0" business is exactly the arithmetic I thought is frowned upon. At least I don't like it. As a programmer I shouldn't have to know that these indices are nonnegative integers. For instances I never use >= 0, I usually use instance_exists(...) because that's what I mean.

Why couldn't there be a collection_exists() function? Like so:

if (collection_exists(mylist)) {
  mylist.something();
}

Or perhaps an is_collection function, similar to is_real and is_string?:

if (is_collection(mylist)) {
  mylist.something();
}

Either would work; just because the syntax would allow for "instance methods" on collections doesn't mean all collection-oriented methods have to be localized.

Edited by IceMetalPunk, 25 January 2011 - 08:42 PM.

  • 0

:GM123: Are you an artist who likes creating original creature designs? Maybe you can help out with Elementa here! Give it a look; you might like the idea :)

:bunny: :excl: :bunny: :excl: :bunny: :excl: :bunny: :excl: :bunny: :excl: :bunny: :excl: :bunny: :excl: :bunny: :excl: :bunny: :excl: :bunny:


#45 Rusky

Rusky

    GMC Member

  • GMC Member
  • 2492 posts
  • Version:Unknown

Posted 25 January 2011 - 08:55 PM

I voted No because I think this will complicate GML without really adding much. Currently, GML is quite simple to learn because it has realatively few features. It's quite easy to understand how GML works. A list had an index, and the index is stored in a variable. To access the list, you need to have the index. To get the index, you must read the variable. The variable works just like any other variable. It's all very intuitive.

This is a possibility, but not a fundamental part of such a change. With stronger types, you would simply change the concept of an index being a transparent integer to an index being merely a reference to something, and nothing else.

mylist = ds_list_create();
mylist.insert( 1, myvalue );
mylist.destroy();
is mylist a local variable holding the list index? Which means that mylist is stored in some instance. So we can do
(other.mylist).insert(1, value)?
Also, can I store the list index in a(nother) variable? E.g. can I now say
var li;
li = choose(mylist1, mylist2)
li.insert(1, value)
...
Can I store the list index in a variable? Also can several instances each have their own mylist (e.g. if I want every enemy instance contain a list of visited nodes)? Can I pass the variable to another instance, e.g. when an enemy wants to know if the enemy it collides with has visited node X)? Can I make a list whose index is global? And how would this be indicated? I'm guessing
(global.mylist).insert(1, myvalue)

mylist, mylist1, mylist2, li and global.mylist are variables holding references. To say it another way, they are names for the actual lists GM is managing for you. Everything would work (storing-indeces-in-variables-wise) exactly the way it did before. You could do other.mylist.insert(1, value), choose(mylist1, mylist2).insert(1, value), global.mylist.insert(1, value), anyexpressionthatresultsinalist.insert(1, value). The only thing you lose is using something that wasn't originally a list as an index, like random(3).insert(1, value).

What would show_debug_message(mylist) do?

This is a little bit more difficult, as it's not something you get for free by implementing collections as part of the type system. With GM's current system, it merely shows you the list's index, something that you don't directly care about. It would be possible to do any number of things, such as showing its address or some other unique attribute (many scripting languages do this) or allowing you to print its contents (this would probably be more useful as a separate operation to allow you the same functionality as the current system).

How can I make my own script for lists? With the current setup I can make a ds_list_swap and have the list index as argument0 and I can then just do

//ds_list_swap(ind, pos1, pos2)
var temp;
temp = ds_list_find_value(argument0, argument1)
ds_list_replace(argument0, argument1, ds_list_find_value(argument0, argument2))
ds_list_replace(argument0, argument2, temp)
With the proposed list syntax, how would such a swap script be defined in GML, in such a way that we can use mylist.swap(pos1, pos2)? Could you give an example of that?

That is another more difficult issue that can be solved in many different ways. Some scripting languages like JavaScript and Ruby allow different forms of this, although it can cause problems with libraries, etc. especially when you override existing operations rather than add new ones. Other languages don't allow this, and with this approach you would just have to stick with the old ds_list_swap syntax.

Finally, can we have something like

mylist.type
to find out whether it's a list or a stack, instance, resource, particle type, etc.? E.g. by using
if mylist.type = ds_list
{
  //code to execute if mylist is a list
}
where ds_list is a built-in constant?

This is one of the major advantages of stronger typing. You can tell what type something is and it's possible to add an interface like this (however using it as in your example is generally a bad idea, especially if you have GM's dynamic typing or some other way of writing generic/polymorphic code).

Edit: also, what about an existence check? You cannot do

mylist.exists()
because if mylist doesn't exist, I would expect an unknown variable error. If this error won't appear, this would be an inconsistency in the system, because right now it's a rule in GML that everything to the left of a dot, has to be defined.

In a system like the one proposed, existence is not a question you ask the index, because if you have an index you already know the list exists. It's impossible for someone to give you a number that might not have a ds_list backing it, they can only give you a number that's just a number. However, a lot of languages allow you to check for the existence of a variable or whether it holds a value. It might be possible to pass a null value (also enabled by an improved type system), in which case you would check if mylist == null, rather than doing ds_list_exists(mylist). This is a stronger guarantee, because you know that if it's a list it actually is list rather than a map or a sprite or a texture.

As you can see, this whole concept raises a lot of questions I'm really not sure about. And that while the current system seems to work fine for me (or at least not worse than the proposed system).

Most of your concerns are not really a problem, as those aspects of the system would not change. The others are all generally improvements over the existing system, so there's nothing to worry about.
  • 0

#46 Manuel777

Manuel777

    InvaderGames

  • GMC Member
  • 3554 posts
  • Version:GM:Studio

Posted 25 January 2011 - 08:58 PM

I voted 'Yes', because i like the idea of being able to point a structure in a so direct way... it's also easyer for me to handle and understand.
  • 0

#47 gnysek

gnysek

    GMC Member

  • GMC Member
  • 583 posts
  • Version:GM:Studio

Posted 25 January 2011 - 09:15 PM

//ds_list_swap(ind, pos1, pos2)
var temp;
temp = ds_list_find_value(argument0, argument1)
ds_list_replace(argument0, argument1, ds_list_find_value(argument0, argument2))
ds_list_replace(argument0, argument2, temp)
With the proposed list syntax, how would such a swap script be defined in GML, in such a way that we can use mylist.swap(pos1, pos2)? Could you give an example of that?

you talking about:
//ds_list_swap(ind, pos1, pos2)
var _oldval;
_oldval = argument0.find(argument1);
argument0.replace(argument1, argument0.find(argument2));
argument0.replace(argument2, _oldval);
Since it should work like instances of objects, I didn't see any problem in it - that's the way that they works now, by references.

What is more fun with this syntax list will works like arrays, and maps like associative array, so we can even think about that syntax:

ds_map_find_value(_data,123) == _data.find(123) == _data[123]
ds_map_find_value(_data,'key') == _data.find('key') == _data['key']
Nice, isn't it? It remind's me PHP now.

Going further:

//example of existing structure
_var1 = ds_list_create();
_var1.add(1,'val');

// new data type
_var2 = ds_array_create(); // now it's like... _var2 = new Array()
_var2.push('value');
for (i=0; i< _var2.size(); i++) //postincrementation will be available in 8.1
{
    show_message(string( _var2.indexof(i) ));
}
In GM6/7/8 you cannot check array size and you must always use another variable to keep that info, and update it by your own. Think about it before saying 'no' to new syntax :)

Edited by gnysek, 25 January 2011 - 09:37 PM.

  • 0

Previously game developer at YoYoGames, Currently PHP developer in DB-Team
Programming and working with: GML/C#/PHP/JS/MySql/CSS/HTML

Follow 
@GameMakerUpdate to get info about latest versions of GM when they are released: https://twitter.com/GameMakerUpdate

(it's managed by bot, not by human, remember)


#48 Docopoper

Docopoper

    You are observant!

  • GMC Member
  • 1287 posts
  • Version:GM:Studio

Posted 25 January 2011 - 09:43 PM

If you are going to add this would you add the vector array types? ie vector2, vector3 and vector4

Edited by Docopoper, 25 January 2011 - 09:43 PM.

  • 0

The first thing I would do with infinite power would be to make myself a cave where I could look at my shadow forever.

 

The destination is much harder to reach when you don't want to walk towards it.


#49 Mike.Dailly

Mike.Dailly

    Evil YoYo Games Employee

  • Administrators
  • 4741 posts
  • Version:GM:Studio

Posted 25 January 2011 - 09:44 PM

Okay... there's too much to respond to directly, so I'll try to revise a little, and address everything at once. Apologies if I miss "your" point, I have read them all and taken everything on board. Take this as a closing argument. I think we could discuss this forever, and I don't want it to get too sidetracked before I close it.

So... First. What does this give us and GML? As I said somewhere, I see this as a stepping stone. We can implement this to live alongside the other collections (which do need rewritten because they're just not very nice/good), and in doing so we can introduce some new concepts to the GML user. Yes, it will be a new step, and yes... these variables my well have TYPE information associated with them (actually.. current variables do as well, but they are just strings or numbers/handles). So, if we added this new variable type, then we could start to introduce the concept of a true object, one with it's own functions.

This is a reasonably small leap for current users. I remember making the same jump when going from C to C++ (which is kinda what this is). We could limit the objects to JUST the new collections, so that you can use the old ones "as is", or you can use the newer, shiny, faster ones. But in doing so, you accept the new method of use. I suspect most would switch if it meant faster, cleaner code.

Down the line.... if this was accepted, we could then start to do the same to instances. Allowing you to attach things to an object/instance, and letting you call methods based on that instance - just like the collection.

One of the biggest things I got when moving to C++, was the concept of a contained object. The "this" pointer. Now GML is actually lucky as it already has this concept, and everyone uses it naturally. Inside the various events, you quite naturally use this concept so I don't think it too big a leap to start using the syntax to go with it. That said, I don't want to do a wholesale switch as that would just annoy everyone. While I mention C++ here, what I really mean is C#. It's implemented much better, has no real use of pointers (well... it does, but in cases where it shouldn't really).

Being a learning tool, one that helps you learn coding with the aim of advancement in your craft/career, I think this would world quite well, as it introduces you to "bigger" concepts that you'll need as you grow as a coder.

So... look at this as a small step. Assume that all the "variable" stuff would just work. That if we introduced TYPES for this specific thing, it would give you enough feedback to make it a natural part of writing your code (and I do accept the chances of getting all this going first time would be...well... not good :) ). If this all worked as you would "hope" it would, and knowing what it would open the gates to (full object control for everything), do you think it's now definitely a bad idea, or one we should "try"? Particularly if it's just a small section of the language, a new addition that had no impact on GML as a whole.

I accept that's a LOT of if's.... But as has been pointed out by others, this allows smaller code, less typing, clearer defined syntax, and niceties (like properties of collections; sizes etc.) that would be very clunky if done as yet more global functions. Global functions are horrible. C# and it's intellisense means I hardly ever have to loop a function up, I type the object a lovely list appears. You don't get that with globals. You have to try and remember them all the time, even if you know the name of the variable your using - I hate that.

So... think on this again... and let me know how you feel about it as a concept. Still dead set against it? Or think it's worth a shot?
  • 0

#50 Docopoper

Docopoper

    You are observant!

  • GMC Member
  • 1287 posts
  • Version:GM:Studio

Posted 25 January 2011 - 09:56 PM

My point! ... I bet you were typing you'r reply when I posted... :-(

I think it is a good Idea, I loved that about C# when I started moving to it (still moving to it).
  • 0

The first thing I would do with infinite power would be to make myself a cave where I could look at my shadow forever.

 

The destination is much harder to reach when you don't want to walk towards it.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users