Some small C4Script design issues

Not logged inOpenClonk Forum

Forum Home Help Search Watchlist Register Login

Topic Development / Developer's Corner / Some small C4Script design issues

Post

By Günther [de]

Date 2010-09-18 00:25

Should we have
foo = bar;
in addition to
local foo = bar;
as toplevel declarations? (both would initialize the property foo of the definition to which the script belongs to bar.)

Should
var a = [1, 2, 3]; a[-4];
throw or return nil? (a[-3] return 1, a[-1] returns 3.)

Should
var a = []; a[3];
increase the array length, or should one have to do a[3]=nil;? (It could also throw, but that wouldn't be helpful.)

Opinions? Justified opinions?

By Zapper

Date 2010-09-18 10:56

>as toplevel declarations? (both would initialize the property foo of the definition to which the script belongs to bar.)

The idea behind that is to have a DefCore like syntax for properties, right? Fine with me

>throw or return nil? (a[-3] return 1, a[-1] returns 3.)

Throw imo. Otherwise someone will start checking whether an array has a specific size by comparing the element with nil. I see it coming!
(On the other hand I still think that a[-1] should be a[GetLength(a)], but, well)

>increase the array length, or should one have to do a[3]=nil;? (It could also throw, but that wouldn't be helpful.)

I would not like to have my array grow when I access members out of range. I'm for an exception there

By MrBeast [de]

Date 2010-09-18 14:12

>Should we have
>foo = bar;
>in addition to
>local foo = bar;
>as toplevel declarations? (both would initialize the property foo of the definition to which the script belongs to bar.)

Any reason for doing that? It may could cause confusing about the range of the variable. (Is it global or local?)

>Should
> var a = [1, 2, 3]; a[-4];
>throw or return nil? (a[-3] return 1, a[-1] returns 3.)

Throw since existing values can be nil, too. ( When nil is returned you can't really decide if it does not exists or is just nil.)

>Should
> var a = []; a[3];
>increase the array length, or should one have to do a[3]=nil;? (It could also throw, but that wouldn't be helpful.)

Again, is there any reason for that? It could create bugs where the length is increased unintentionally. (And thus do something unitended in "for(var x in array)" or other things which uses all values.)

By Günther [de]

Date 2010-09-18 15:36

> Any reason for doing that? It may could cause confusing about the range of the variable. (Is it global or local?)

We have local Name = "Name"; in about every Script, shortening that saves a significant amount of boilerplate. I don't think it'll be confusing, nobody is confused about whether functions are global or local either.

> Throw since existing values can be nil, too. ( When nil is returned you can't really decide if it does not exists or is just nil.)

With an exception you can't do anything either, you have to go change the script to check the array length before accessing it. You don't need an exception to write the check. The question it whether you'd make the code pretend that the value is nil, or substantially rewrite it because the exception highlighted a genuine error in the script.

> Again, is there any reason for that?

No, the engine just happens to do that at the moment.

By Zapper

Date 2010-09-18 16:28

>We have local Name = "Name"; in about every Script, shortening that saves a significant amount of boilerplate. I don't think it'll be confusing, nobody is confused about whether functions are global or local either.

I think we need a macro for that anyway. Having Name="$Name$" (and other standard properties) in every object does not seem very clean to me

By Carli

Date 2010-09-18 15:01

>Should
> var a = []; a[3];
>increase the array length, or should one have to do a[3]=nil;? (It could also throw, but that wouldn't be helpful.)

in gwx, we throw because the example a[1999999] is a fault AND creates unwished results.

By Isilkor Date 2010-09-18 18:24

Can you catch exceptions in gwx? This is currently not possible with C4Script, which is why an exception would not be too useful here; once/if we implement exception handling, I'd agree throwing would be a good solution though.

By Zapper

Date 2010-09-18 20:07

If the exceptions work as an runtime error for the time being it would be okay with me

By Carli

Date 2010-09-19 14:28

I forbid "catching" because it leads to a bad coding style "it does not work so I make a try-catch-block around it so the rest of the code will work"

"exceptions" are handled as a runtime error and stop the whole execution of the script and you get an error as your function result.

By Caesar

Date 2010-09-19 16:18

In a real oop exceptions do make sense. For example, you can put the checking stuff where it thematically belongs. And you don't have to do an extra return type for all functions to cover all the errors that could occur. I think just forbidding stuff because it could lead to a bad coding style is an incapacitation of the coders.

By Günther [de]

Date 2010-09-29 22:47

I went with not doing the work for the first, making the engine not throw/return nil for the second and leaving the length alone on access for the third. The first one might change later, or maybe someone else wants to implement that? It should be a simple patch to src/script/C4AulParse.cpp.

Topic Development / Developer's Corner / Some small C4Script design issues

Post