Jump to content


Collections...


  • This topic is locked This topic is locked
77 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

  • Guests

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

#2 Nocturne

Nocturne

    Nocturne Games

  • Administrators
  • 22053 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

#3 gnysek

gnysek

    GMC Member

  • GMC Member
  • 541 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

#4 TheSnidr

TheSnidr

    That guy

  • Global Moderators
  • 3024 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
  • 4927 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
  • 3189 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

#7

  • Guests

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.

#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

#9 gnysek

gnysek

    GMC Member

  • GMC Member
  • 541 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

#10 Derme

Derme

    Time for a break.

  • GMC Member
  • 458 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

#11 Robert3DG+

Robert3DG+

    Designer

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

Posted 25 January 2011 - 10:26 AM

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

#12 Schyler

Schyler

    Noskcirderf Derf

  • GMC Member
  • 2679 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

#13 dadio

dadio

    I miss my cupcake

  • YoYo Games Staff
  • 2033 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

#14

  • Guests

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

#15 gnysek

gnysek

    GMC Member

  • GMC Member
  • 541 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

#16 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

#17 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

#18 Smarty

Smarty

    GMC Member

  • GMC Elder
  • 7470 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

#19 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

#20 Schyler

Schyler

    Noskcirderf Derf

  • GMC Member
  • 2679 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

#21 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

#22

  • Guests

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.

#23 Smarty

Smarty

    GMC Member

  • GMC Elder
  • 7470 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

#24 gnysek

gnysek

    GMC Member

  • GMC Member
  • 541 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

#25 Smarty

Smarty

    GMC Member

  • GMC Elder
  • 7470 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

#26

  • Guests

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.

#27 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

#28 Smarty

Smarty

    GMC Member

  • GMC Elder
  • 7470 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

#29 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

#30 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




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users