49 replies to this topic

[BlueMoonProductions]

This should also give error.

You mean: variable and variable[0] should be separated.

[gnysek]

The current idea, is that if you use argument[x], then it'll be as normal. So no checking. But most folk will use argument0, argument1 etc. All you'd have to do is rewrite your function to use argument[0] and argument[1] instead

I'm thinking about this dim... because now when I write script:

//myScript
if (argument3) draw_set_color(argument3) else draw_set_color(c_white);
draw_text(argument0, argument1, argument2);

I need to call it by myScript('text',0,0,0) in 8.1 (in 8.0 it can be myScript('text');).

You said, that argument[x] will be not checked in this case. But, since we use dim, If I'll write:

if (argument[3]) draw_set_color(argument[3]) else draw_set_color(c_white);
draw_text(argument[0], argument[1], argument[2]);

then use it as myScript('text');, argument[1..3] will be not set and give me error, because I need to use dim(argument,4), before right?

Edited by gnysek, 09 April 2011 - 11:05 AM.

[sabriath]

@gnysek, your coding is terribly implemented. You are checking if an argument is '0' in order to check the boundary....Mike just stated that "argument_count" is a good idea, so you should be checking that instead.

if(argument_count > 1)
{
  //do stuff with argument[]
}

From reading what Mike is putting here, it seems that anytime 'argument' is used in this way, then it will allow variable argument assignment, where otherwise the highest value 'argument#' is used as the last parameter strictly. This means that it will be done at parsing and compile time, not runtime....it's as simple as doing a search of your scripts:

parsing:
-for each script
--does it use 'argument[]'...if so, mark this script as 'any number of arguments allowed'
--otherwise, look for all 'argument#', what's the highest '#', mark this script as 'requiring N arguments' where 'N' is #+1

compiling:
-when 'ident' is reached at any point and it is a script call
--if 'any number of arguments allowed' is marked, compile without errors
--otherwise if 'requiring N arguments', make sure 'N' arguments are supplied, give error if not


It's a pretty simple concept...so I don't see how a lot of you are not understanding.

[gnysek]

It was just the shortest example But yes, with argument_count it's no longer a problem.

[NakedPaulToast]

Dim(myarray,16);

OK

What about a two dimensional array?

Dim(myarray,16,16);

Oops.

I'm thinking:
dim(myarray[16]);
dim(myarray[16,16]);

[TheMagicNumber]

If you're going to have a function to create arrays, don't name it dim.

@NPT: Although that would be nice, it doesn't really fit into GML.

[Shadowrend]

The "dim()", function would be cool, but it would also be nice that it has no capital letters ("dim" not "Dim"), for easier typing.

As for the script arguments, I sometimes don't type them on purpose.
For example, in my drop down menus, I have a script add_menu(NAME,SHORTCUT,SPRITE), If for example the script has no sprite, I would just type add_menu("Button","Ctrl+B"), and if it has, I'd add a ", spr_button" as argument3.

Also, I agree on the argument_count function, as it can be handy at some times.

PS: I also have one request. It is not about this one, but about the image editor. Could you instead of having, for example Blur, we have Small, Medium and Large, could we type a number instead (0-100).

[paul23]

As for the script arguments, I sometimes don't type them on purpose.
For example, in my drop down menus, I have a script add_menu(NAME,SHORTCUT,SPRITE), If for example the script has no sprite, I would just type add_menu("Button","Ctrl+B"), and if it has, I'd add a ", spr_button" as argument3.

You notice that by doing this (I assume you hence check for "if argument3 == 0" or something?) you have a huge (potential) bug in your code? - The first sprite you create in a project has always index "0"...

On top of that, the current syntax is preserved by using argument[x], requires just a small rewrite of your scripts.

Edited by paul23, 09 April 2011 - 04:09 PM.

[Rusky]

You say you're going to rewrite all this, but wouldn't it be better to just put in the effort in the first place? It would be rather useless to have more ad-hoc implementations of the functionality you want only to remove it all in the next version.

The ideal solution would be to support arrays as first-class values (preferably dynamically resizable like in other dynamic languages):

var array = [ "some value" ]
show_message(array[3]) // error
array[3] = "hello world"
show_message(array[3]) // "hello world"
show_message(array[1]) // error

This way you could solve the arguments problem much more nicely, with an arguments array and then named arguments that refer to its elements:

// some_script(a, b, c)
do_stuff_with(a, b, c)
for (var i = 0; i < arguments.count; i += 1)
    do_other_stuff_with(arguments[i])
show_message(arguments[5]) // error

Optional arguments could be set up in the script editor to have default values the same way you name them:

// assume some_script(a, b = 3)
some_script(3)
some_script(4, 5)
some_script(6, 7, 8) // error

Finally, variadic arguments could also be set up in the script editor:

// some_script(a, *b)
// arguments is an array of [a, [stuff, in, b]]
// called as some_script(1, 2, 3, 4, 5, 6)

show_message(a)
for (var i = 0; i < b.count; i += 1)
    show_message(b[i])

It would be especially nice to support dictionaries/hashes/associative arrays/maps for keyword arguments:

// some_script(a, **b)
// arguments is an array of [a, {stuff = in, argument = b}]
// called as some_script("foo", bar = "baz", quux = "quux")

show_message(a)
for (var key : b)
    show_message(key + " => " + b[key])

Note that I'm not suggesting that everything be exactly this way, just that it have this functionality- the syntax could be very different and everything else would still be perfectly fine.

Edited by Rusky, 09 April 2011 - 04:13 PM.

[Erik Leppen]

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.

[IsmAvatar]

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.

[Erik Leppen]

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.

[Josh @ Dreamland]

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.

[paul23]

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

[GameGeisha]

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

[Erik Leppen]

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?

[Drara]

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

[LSnK]

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.