Jump to content


Uninitialised "things"


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

#31 Erik Leppen

Erik Leppen

    GMC Member

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

Posted 09 April 2011 - 04:42 PM

I don't like this entire argument thing. The first reason: you sacrifice backwards compatibility to GM8.0. Code that works in 8.0 could now be erroneous in 8.1 because not all arguments are used. So given this, this is more of a 9.0 thing than a 8.1 thing.

Also I think this makes things a lot less intuitive. Right now it's just argument0 to argument15 or argument[0] to argument[15] and they will always work and is very straightforward to understand. What you propose is that Game Maker secretly guesses the number of arguments from the code, and I hate computer programs secretly guessing what I mean by things. I much much prefer the ability to explicitly set the number of arguments myself. So what I would much prefer to this, is what the Extension Maker does. Every extension function has a setting "number of arguments" that can be set to 0, 1, 2, ..., 13, 14, 15, 16 or Arbitrary. Add the same setting to the script editor. Arbitrary is the default, this will be the same behavior as GM 8.0. A programmer that wants this can set the number of arguments to a fixed value himself. This way it is always optional, without having to change argument3 to argument[3] in every script, and as a bonus you keep backwards compatibility.

I also think adding a new function/variable argc to give you the number of arguments, would be a damn fine idea...

Please call this argument_count or argument_number. argc is just some a meaningless string of symbols, and one of the reasons I like GM is that it doesn't come with loads of meaningless names for functions and variables. Please conform to the current naming system. argument_count and argument_number are logical and meaningful names. argc isn't.

Edit: typo

Edited by Erik Leppen, 09 April 2011 - 05:52 PM.

  • 4

#32 IsmAvatar

IsmAvatar

    Good Samaritan

  • GMC Member
  • 2411 posts
  • Version:GM8

Posted 09 April 2011 - 05:43 PM

Could we make it lowercase d dim, rather than breaking convention and starting with a capital letter?

Or frankly, even array_init would be great. That keeps to convention pretty well and avoids breaking things where people use "dim" as a variable.

Could you also make an array_free - or some method of freeing an array?

Edited by IsmAvatar, 09 April 2011 - 05:44 PM.

  • 3

#33 Erik Leppen

Erik Leppen

    GMC Member

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

Posted 09 April 2011 - 05:51 PM

Or frankly, even array_init would be great.

Note that this is not a normal GM function. I mean if this were a normal function,
array_init(myarray, etc.)
would try to read the value from the variable myarray and then execute the function on its value. However what is meant is using the name myarray. Actually, it is more like
variable_local_array_set("myarray", etc.)

Edit: What I'd like to see for this dim thing, is
dim myarray[2..10] = 1
which sets myarray[2] up to myarray[10] to value 1. And actually, the dim keyword could be omitted if two dots becomes a GML keyword denoting a range. Then we can simply have
myarray[2..10] = 1
and suddenly it looks a lot like just declaring a normal variable.

Edited by Erik Leppen, 09 April 2011 - 05:54 PM.

  • 3

#34 Josh @ Dreamland

Josh @ Dreamland

    GMC Member

  • New Member
  • 455 posts
  • Version:GM8

Posted 09 April 2011 - 06:03 PM

Note that this is not a normal GM function. I mean if this were a normal function,

array_init(myarray, etc.)


would try to read the value from the variable myarray and then execute the function on its value. However what is meant is using the name myarray. Actually, it is more like


Ism was merely using the same parameter format forwarded by Mike with dim(i,20). It's clear that either he intends to change that behavior to accept references (which would be rather interesting), or he was speaking in a less literal sense.

I'd like to second the notion of array_init; Dim() breaks a long-standing convention, most people don't live long enough to type variable_local_array_set every time they want something done, and `dim' shadows a BASIC instruction.

That said, I'm also with Rusky on the proposal to allow i = [1, 2, 3], or for that matter, shamelessly steal from MATLAB and allow i = [1..20], or, though I can't imagine it, i[0..20] = 0. I'm not fond of the latter proposal, but i = array(20,0) would be fine. The first issue I believe you'll run into is that GM doesn't have default parameters, so the 0 must be explicit or the system must be modified. It also doesn't allow setting arrays... perhaps you could consider defining a new operator for array copy. Really, I'm just throwing out some ideas.

As for your script parameters, what I have done is this:
1) Move argument0 and co. into the script scope, as you seem to have already taken for granted,
2) Allow an unlimited number of parameters (any reference to argument# will be accounted for),
3) Default all used arguments to zero (so if they are passed, only necessary copying is done, while if they are not, no unused variables are set).

That introduces one vulnerability, namely, if you use only argument0 and argument256, you will end up with 256 parameters of useless slag. Considering how queer a scenario that is, I choose to ignore it completely and assume no one will ever notice.
  • 0

#35

  • Guests

Posted 09 April 2011 - 07:09 PM

argument[ ] does not need to be "dim()'d", as it's already implicitly setup by the calling function and has filled in all the values for you. My preference would be to have accessing argument[argument_count+1] throw an error, because once you have access to the number of arguments there is no excuse to go outside them. Anyone got a valid reason?

Unfortunately, all this is RUNTIME, not compile time. This means you'll get a runtime error. Not my preference, but it's the simplest way of implementing it. If I did it any other way, it would take for ever to write; so runtime it is. Sorry.
Aside from that; yes. If you access only one argument; say argument12, then I'll expect 13 arguments to be passed. If you use argument[x] instead, then it simply won't bother checking argument counts.

dim(blah,16,16) - yes. Good point. I'll have to check, but I think I can have variable numbers of args in system functions.

dim is a well known BASIC function. It's also short, and easy to remember. I see no reason to call it array_init(). I'm happy to keep it lower case, and happy to rename argc (which, in C means argument count) to argument_count.

I've already said this. If you WANT to drop arguments, you'll be able to use the syntax argument[x].

I'm currently making no further changes to the image editor.

Rusky, this is a quick fix. We have countless issues with this kind of error. It's bad practice, and it's a bug waiting to happen for most folk. Everyone will simply forget to type the right number of parameters in now and then. So we're going to fix it now. The better and cleaner the code, the more we can do with it later.
I've also already said we won't be doing named arguments in this version.

Erik Leppen: I don't really care about backwards compatibility when the thing I'm breaking is bad coding and bugs. :)
LOL - it's hardly a GUESS!! You've accessed up to argument3 in your script, so you NEED to pass 4 arguments. Hows that a secret guess? You've already dictate how many arguments you'll be using by... well... using them in your script!

argument_count it is. I have no problem calling it that. (That said. Programming is FULL of abbreviation and funny names, you really should get used to them. If you want a fright, look up the SIMD instruction set, now there's a set of scary command names.) :)

I'll look into a way to free an array. I agree, it would be nice! Of course... we could make dim() resize it down as well.... dim(1) would be the smallest.

I would love to have one of these...

var arr[x][x]
dim arr[x][x]
dim array[x][x], 0


array[1..10]=?? could be interesting too.


However, all these would take significant work, not the least making sure we haven't broken everything else!! They modify the base syntax, where as dim() is just another command. So for this version, dim() it is. Sorry.

I've also already said we won't be adding extra parameters. We'd like to, but there are big issues with that. You'll only get that once we rewrite it all.

I agree. If some one only uses argument0 and argument3, then I say that's a bug, as clearly they'd have to pass 4 arguments for that code to work correctly! As I said before... not forcing this is a bug waiting to happen. Also consider newbies using argument1 instead of argument0, simply because they think it starts at 1.

#36 paul23

paul23

    GMC Member

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

Posted 09 April 2011 - 08:49 PM

There's another thing I'm afraid happens here:

you make it sound like the error happens during script execution (script uses more arguments than caller provided). However the caller is in my eyes the one responsible to give the script the desired amount of arguments. I'm just hoping the error message makes this clear (that you made a mistake when calling the script not a fault in the script itself).
  • 0

#37 GameGeisha

GameGeisha

    GameGeisha

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

Posted 09 April 2011 - 08:56 PM

I agree. If some one only uses argument0 and argument3, then I say that's a bug, as clearly they'd have to pass 4 arguments for that code to work correctly! As I said before... not forcing this is a bug waiting to happen. Also consider newbies using argument1 instead of argument0, simply because they think it starts at 1.

Is there anything wrong with teaching the newbies that numbering in programming usually starts at 0?

GameGeisha
  • 0

#38 Erik Leppen

Erik Leppen

    GMC Member

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

Posted 09 April 2011 - 09:17 PM

What I am a bit worried about is that this argument behavior silently changes along with changes within the script. I mean, if the script changes, this can make all calls to it erroneous in one go. I mean, if I have a script with four arguments, that looks like this:
//function(a0, a1, a2, a3)
repeat argument3
{
  //do something with argument0, argument1 and argument2 only
}
Commenting out variable parts and replacing them by fixed numbers is a viable way of debugging things. So I could want to comment out the argument3 from the repeat statement and replace it with a fixed number, to see if it does what I want it to do. However when I do this, argument3 disappears from the code (as it's in a comment), making all calls to this script erroneous.

In GM8.0 everything keeps working as usual. However in GM8.1 the number of arguments has silently changed (yes, silently, unless GM's IDE shows me the argument count somewhere and I can see that it changes. It's obvious now, but it isn't in a 200 line script). Running the game would generate errors in the script call. This can be confusing, as I didn't even make changes to the script call. Also, to fix the problem, I don't need to fix the script call (as that is not the problem), but I need to change the argument count of this script back to 4. This can only be done by introducing argument3 into the code, e.g. like this:
var unused; unused = argument3
//rest of the script here
I think this is a very weird and counter-intuitive way of setting the number of arguments, may the need arise.

I'm perfectly happy with scripts having a fixed number of arguments. I'm just not very happy with Game Maker determining this argument count itself. If I, the programmer, can set the number of arguments, I'm perfectly fine with this, in fact I'd like it a lot. The only thing I don't like is that the argument count is implied, rather than explicit. I understand it's probably too much work to add an input field for that in the script editor, but I'm still not perfectly happy with the current approach.

 
Also, do I understand correctly that whenever the script contains argument[n], the number of arguments in the call is arbitrary? So can I do this:
return instance_create(argument0, argument1, argument[2]) //note the [2] here
and still call the script with any number of arguments, that could differ throughout the game? And what does argument1 give when I call it with one argument or fewer?
  • 1

#39 Drara

Drara

    GMC Member

  • GMC Member
  • 320 posts

Posted 09 April 2011 - 09:32 PM

I can't realy stay behind all this thing. I use myself scripts with not fixed numbers of arguments too and I presume that when I don't give one or more arguments (out of lazyness), those arguments give 0.
Now we should switch to the array arguments instead, it's ok, but: As far as I know, accessing arrays is slower then accessing variables. So you would loose the speed up you may get at calling the thing by accessing the array...
I can't help but GM 8.1 is something like an update. It should be fully compatible with old projects in my oppinion without changes...
  • 0

#40 LSnK

LSnK

    NaN

  • GMC Member
  • 1188 posts

Posted 09 April 2011 - 09:47 PM

dim is a well known BASIC function. It's also short, and easy to remember. I see no reason to call it array_init(). I'm happy to keep it lower case, and happy to rename argc (which, in C means argument count) to argument_count.

Isn't fitting in with the existing functions reason enough? It's easier to learn a verbose naming scheme than a homogenueous one, and that ease of acclimatisation should be at the forefront when considering names for new features.

I'm guessing you grew up with a C64, but bear in mind that most GM users have no such exposure. If they've ever seen that syntax at all, odds are it was part of a GOTO joke. :p


Now we should switch to the array arguments instead, it's ok, but: As far as I know, accessing arrays is slower then accessing variables. So you would loose the speed up you may get at calling the thing by accessing the array...

It's technically slower, but the difference is so miniscule it's not even worth talking about.
  • 0

#41 sabriath

sabriath

    12013

  • GMC Member
  • 3189 posts

Posted 09 April 2011 - 10:16 PM

If you want a fright, look up the SIMD instruction set, now there's a set of scary command names

Those aren't so scary....
pack
unpack
signed saturation
unsigned saturation
byte
word
double word
low
high
packed...
..add
..multilply
..subtract
..multiply then add
etc.

odds are it was part of a GOTO joke

Why does everyone hate 'goto' so much? How else do you break out of a second/third/Nth tier nested switch/for/otherloop block efficiently?



As for arguments in scripts...I just thought of something, what if you had:

execute_string("somevar = argument12;");

Obviously GM wouldn't know that "argument12" is being used...this severely breaks a vital piece of GM's coding ability, and what makes it versatile. Although I do agree that a boundary should be made, it should be left up to the programmer instead of automatic (Erik gives another example of such a failure in GM if used automatically).
  • 0

#42 kburkhart84

kburkhart84

    Firehammer Games

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

Posted 10 April 2011 - 12:20 AM

If you want a fright, look up the SIMD instruction set, now there's a set of scary command names

Those aren't so scary....
pack
unpack
signed saturation
unsigned saturation
byte
word
double word
low
high
packed...
..add
..multilply
..subtract
..multiply then add
etc.

odds are it was part of a GOTO joke

Why does everyone hate 'goto' so much? How else do you break out of a second/third/Nth tier nested switch/for/otherloop block efficiently?



As for arguments in scripts...I just thought of something, what if you had:

execute_string("somevar = argument12;");

Obviously GM wouldn't know that "argument12" is being used...this severely breaks a vital piece of GM's coding ability, and what makes it versatile. Although I do agree that a boundary should be made, it should be left up to the programmer instead of automatic (Erik gives another example of such a failure in GM if used automatically).


About GOTO, as far as I know, its like a singleton. It is supposedly not recommended, but yet it is known to be useful and simply works. And I'm guessing because of how known that story is, it got turned into joke material, similar to Chuck Norris.

About execute_string, that would suck to lose that function. I'd rather risk GM not being able to detect arguments being used in strings than to lose that function. But that's just me. Sadly enough, execute_string somewhat falls into the same category I mentioned above about GOTO and the singleton.
  • 0

#43 Dangerous_Dave

Dangerous_Dave

    GMC Member

  • Global Moderators
  • 9413 posts
  • Version:Unknown

Posted 10 April 2011 - 02:57 AM

Is there anything wrong with teaching the newbies that numbering in programming usually starts at 0?

While we're here, are we making character positions in strings start at 0? If we are teaching them numbering starts at 0, let's keep it consistent.
  • 0

#44 Desert Dog

Desert Dog

    GMC Member

  • GMC Elder
  • 6409 posts
  • Version:Unknown

Posted 10 April 2011 - 04:03 AM

After some thought, I give the array error thing a check.

I'm a bit more tentative about the fixed script argument thing, it reduces flexibility a touch, but the speed increase is worth it for me, so check that, too.

I am wondering about backwards compatability, though.
  • 0

#45 Dangerous_Dave

Dangerous_Dave

    GMC Member

  • Global Moderators
  • 9413 posts
  • Version:Unknown

Posted 10 April 2011 - 04:24 AM

The fixed script arguments aren't reduced in flexibility, as anything you could do before can still be done but you will need to use the argument array (argument[x]) instead of the argument variables (argument0, argument1...).

As far as backwards compatibility goes, there are very few reasons why people should be having an unknown number of arguments, so almost no one should be doing anything that will now cause errors. Those that are can simply change argument0 to argument[0] and all is fixed.
  • 0

#46 TheMagicNumber

TheMagicNumber

    GMC Member

  • GMC Member
  • 5247 posts
  • Version:Unknown

Posted 10 April 2011 - 05:18 AM

var realOrStr;
dim(array, 10, 0);
Why not be consistent and have:
var realOrStr;
var array[10];
variable_array_clear("array", 0);
You could always have the var statement accept initial values, and assume the initial value for an array is for all elements.

GM is already C and Pascal style, don't add on crap from BASIC now.

Edited by TheMagicNumber, 10 April 2011 - 05:18 AM.

  • 4

#47 Manuel777

Manuel777

    InvaderGames

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

Posted 10 April 2011 - 04:05 PM

GM is already C and Pascal style, don't add on crap from BASIC now.

Sometimes we can aaall agree with you TMN, sometimes :)

going back to the arguments stuff, i really liked the argc and dim() implementations.. but letme get this straight; calling a script:
MyScriptName(value,x,y,"Hello");
will have four arguments, so the argc will be four, and thats it.. you dont need to go trough all the 15 arguments to initialize them as zero.. i really never saw the point on that since no other languaje does it and it may turn buggy (as mike stated)
So, an error when you try to access argument[5] in the function above would be a nice idea, something like "Uninitialized argument [5] on function MyScriptName [blah blah]"
An here is where dim() comes in, in case you want to define initialized arguments as zero? Am-i-rite?? (if so i like it a lot)
  • 0

#48 broadsword

broadsword

    GMC Member

  • New Member
  • 345 posts

Posted 10 April 2011 - 04:20 PM

My only concern with the argument change is that I currently use it to overload scripts in GM. For example consider this function/script:

show_dialog(x,y,string,width,height,txt_speed,skip_key);

by adding the following to that script:

var width, height; //,etc...
width = 200;
height = 100;

if (argument3) width = argument3;
if (argument4) height = argument4;
//etc...

I can call show_dialog like this to use default values:

show_dialog(x,y,string);

Will this new error handling remove this functionality and if so, will there be any other way to overload a script in GM?
  • 0

#49 kburkhart84

kburkhart84

    Firehammer Games

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

Posted 10 April 2011 - 06:22 PM

My only concern with the argument change is that I currently use it to overload scripts in GM. For example consider this function/script:

show_dialog(x,y,string,width,height,txt_speed,skip_key);

by adding the following to that script:

var width, height; //,etc...
width = 200;
height = 100;

if (argument3) width = argument3;
if (argument4) height = argument4;
//etc...

I can call show_dialog like this to use default values:

show_dialog(x,y,string);

Will this new error handling remove this functionality and if so, will there be any other way to overload a script in GM?


It has already been stated that using the array method to access arguments(like argument[5]) would keep the old functionality.
  • 0

#50

  • Guests

Posted 11 April 2011 - 09:15 AM

okay... closing this one down now.

The rules are;

  • if you use argument0 to argument15, then you MUST supply up to that number in the argument list. So if you use argument2, you must supply 3 arguments - exactly.
  • If you use the argument array (argument[x]) then you are free to supply as many or as few arguments as you wish.
  • If you use both argumentX and argument[x], then you MUST supply up to argumentX, but are free to supply more if you wish. So if you use argument1 and argument[x], then you must supply at LEAST 2 arguments, but can then use any optional ones that have been passed in.
  • argument_count will hold the number of arguments passed. (0 is for no arguments passed)
  • accessing argument[argument_count] or higher, will throw an error.


If/When I come to do arrays (Prob won't get into 8.1, but not sure yet), I'll post those rules as well.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users