If you could change one thing about GScript, what would it be?

[cbk1994]

If you could go back in time before GS2 and change any one thing about it, what would it be? Compatibility with old code is not a problem—even a change as drastic as strict typing is acceptable for this exercise. Ideally they will be entirely language-related and not things such as documentation, version control, etc.

My one thing:
I would make objects use a strict class system, and make it easy for scripters to edit these object classes. There would be a list of scripts much like the NPCs list for object classes (not related to classes now). These classes would have constructors, and support inheritance. All object types (such as GuiScrollCtrl) would work in this fashion (although they would not appear in this class list) and could be extended by objects. I could make a class called GuiIPhoneScrollCtrl which extends GuiScrollCtrl and has iPhone-like scrolling.

[fowlplay4]

Remove the need for temp prefixing.

[Crow]

Originally Posted by fowlplay4

Remove the need for temp prefixing.

I'm just curious: What would you prefer instead? No prefixes for temporary vars at all, instead using constructors for global vars?

[fowlplay4]

Originally Posted by Crow

I'm just curious: What would you prefer instead? No prefixes for temporary vars at all, instead using constructors for global vars?

Yeah something like that, and maybe a global prefix.

This would be my target result:

PHP Code:

function onCreated() {
  a = 1;
  b = 2;
  otherFunc();
  echo(a SPC b); // with change it echos "1 2" currently it echos "2 1"
}

function otherFunc() {
  a = 2;
  b = 1;
} 


[WhiteDragon]

Make it based on a dependent type theory.

More realistically: make it much, much closer to JavaScript. Essentially, ECMAScript with a DOM-like interface to Graal.

[Mark Sir Link]

ability to restrict query execution/variable changes to certain classes/weapons/NPCs

[smirt362]

The lack of masking support
http://forums.graalonline.com/forums...hp?t=134263607

[Twinny]

Originally Posted by Mark Sir Link

ability to restrict query execution/variable changes to certain classes/weapons/NPCs

Been requested so many times...can only hope!

[Mark Sir Link]

Originally Posted by Twinny

Been requested so many times...can only hope!

http://forums.graalonline.com/forums...hp?t=134260502

[MrDunne]

Fix anonymous functions.

[Chompy]

Originally Posted by MrDunne

Fix anonymous functions.

Elaborate.

[WhiteDragon]

Originally Posted by Chompy

Elaborate.

There are a few problems.

• In certain cases, when passing around an anonymous function, you lose the ability to call it. I think the problem is when you call the anonymous function from a different class than it was defined, but I'm not certain exactly when it happens. (If someone wants to debug this, please do.)
  
  My current hack around this is, given a function temp.f, doing (@temp.f)(), which casts the function pointer to a string like "function_913727", which is a global variable and can be called from anywhere as a result.

• When a class using anonymous functions is updated, most things break until you update the NPC/Weapon that they are joined to.

• More of a feature request than a bug, but it'd be great if we had proper function closures.

[MrDunne]

Originally Posted by Chompy

Elaborate.

Originally Posted by WhiteDragon

There are a few problems.

• In certain cases, when passing around an anonymous function, you lose the ability to call it. I think the problem is when you call the anonymous function from a different class than it was defined, but I'm not certain exactly when it happens. (If someone wants to debug this, please do.)
  
  My current hack around this is, given a function temp.f, doing (@temp.f)(), which casts the function pointer to a string like "function_913727", which is a global variable and can be called from anywhere as a result.

• When a class using anonymous functions is updated, most things break until you update the NPC/Weapon that they are joined to.

• More of a feature request than a bug, but it'd be great if we had proper function closures.

Mainly this. There's also this:

PHP Code:

function onCreated() {
  temp.func = myTest();
  (@ temp.func)();

  myOtherTest(function () {
    echo("yeah baby");
  });
}

function myTest() {
  return function () {
    echo("yeah baby");
  };
}

function myOtherTest(func) {
  (@ func)();
} 


Produces the following:

Script compiler output for *scratch*:
error: unexpected token: function at line 3: myOtherTest(function () {
error: unexpected token: ( at line 3: myOtherTest(function () {
error: unexpected token: ) at line 3: myOtherTest(function () {
error: unexpected token: ) at line 5: });
error: unexpected token: function at line 13: return function () {
error: unexpected token: ( at line 13: return function () {
error: unexpected token: ) at line 13: return function () {

It doesn't seem right to me.

[WhiteDragon]

Originally Posted by MrDunne

There's also this: ...

That's a result of the GS2 grammar not being flexible enough. Ideally, anonymous functions would be listed as expressions (so you could put them anywhere you could put, say, true), but they seem to only be allowed in variable assignments (i.e., temp.f = ...).

One nifty hack around this one is, for example, return (temp.f = function () { ... } );. But that's rather ugly and I certainly don't do it .

But yeah, that is indeed another thing that should be changed and should be fairly straightforward.

[MrDunne]

Originally Posted by cbk1994

I would make objects use a strict class system, and make it easy for scripters to edit these object classes. There would be a list of scripts much like the NPCs list for object classes (not related to classes now). These classes would have constructors, and support inheritance. All object types (such as GuiScrollCtrl) would work in this fashion (although they would not appear in this class list) and could be extended by objects. I could make a class called GuiIPhoneScrollCtrl which extends GuiScrollCtrl and has iPhone-like scrolling.

I kinda disagree here. I think pushing GS's object system more towards Javascript and prototypical OO would be far better. I think it'd be way easier going in that direction than going back and redoing it in a different style of OO.