Graal Forums

Graal Forums (https://forums.graalonline.com/forums/index.php)
-   NPC Scripting (https://forums.graalonline.com/forums/forumdisplay.php?f=8)
-   -   If you could change one thing about GScript, what would it be? (https://forums.graalonline.com/forums/showthread.php?t=134263610)

cbk1994 06-20-2011 08:30 AM
If you could change one thing about GScript, what would it be?
 
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 06-20-2011 03:03 PM
Remove the need for temp prefixing.

Crow 06-20-2011 03:25 PM
Quote:
Originally Posted by fowlplay4 (Post 1655482)
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 06-20-2011 03:41 PM
Quote:
Originally Posted by Crow (Post 1655483)
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 06-21-2011 07:01 AM
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 06-21-2011 08:25 PM
ability to restrict query execution/variable changes to certain classes/weapons/NPCs

smirt362 06-22-2011 05:50 AM
The lack of masking support
http://forums.graalonline.com/forums...hp?t=134263607

Twinny 06-22-2011 01:10 PM
Quote:
Originally Posted by Mark Sir Link (Post 1655650)
ability to restrict query execution/variable changes to certain classes/weapons/NPCs
Been requested so many times...can only hope!

Mark Sir Link 06-22-2011 08:41 PM
Quote:
Originally Posted by Twinny (Post 1655769)
Been requested so many times...can only hope!
http://forums.graalonline.com/forums...hp?t=134260502

MrDunne 07-01-2011 01:00 AM
Fix anonymous functions.

Chompy 07-01-2011 01:20 AM
Quote:
Originally Posted by MrDunne (Post 1656878)
Fix anonymous functions.
Elaborate.

WhiteDragon 07-01-2011 02:05 AM
Quote:
Originally Posted by Chompy (Post 1656880)
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.

MrDunne 07-01-2011 09:22 AM
Quote:
Originally Posted by Chompy (Post 1656880)
Elaborate.
Quote:
Originally Posted by WhiteDragon (Post 1656885)
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.
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:

HTML Code:
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 07-01-2011 09:42 AM
Quote:
Originally Posted by MrDunne (Post 1656905)
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 :p.

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

MrDunne 07-01-2011 01:17 PM
Quote:
Originally Posted by cbk1994 (Post 1655466)
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.

cbk1994 07-01-2011 03:50 PM
Quote:
Originally Posted by MrDunne (Post 1656922)
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.
It would certainly be easier to do that, but I think ultimately GScript would be better if it had used a strict system. Keep in mind:

Quote:
Originally Posted by cbk1994 (Post 1655466)
Compatibility with old code is not a problem—even a change as drastic as strict typing is acceptable for this exercise.
On that note, I've proposed JS-like prototypes for GScript multiple times and would love to see them added.

MrDunne 07-01-2011 08:13 PM
Quote:
Originally Posted by cbk1994 (Post 1656926)
It would certainly be easier to do that, but I think ultimately GScript would be better if it had used a strict system. Keep in mind:



On that note, I've proposed JS-like prototypes for GScript multiple times and would love to see them added.
I still don't buy it. Keeping backwards compatibility and adding a class-based system on top of it sounds like a really bad idea.

The main reason being is that's the main path C++ took and it's a horrendously complex language. There's an old saying but I can't remember it but it goes something like once is a tragedy but repeated again is a fallacy. It's essential repeating the mistakes of the past but even worse so because you have 2 object systems on the go (you know, for backwards compat).

Why 2? Well, Graal has an object system which has features which are distinct from that of a class-based system. I think you know what I'm talking about: you can create a base object and join some classes to it. You can then clone that object and, if I remember rightly, the members will remain. This isn't very classical.

To gel the two together, like C++ OO was squeezed on top of procedural language, you'll be doing something similar but squeezing one OO type onto another OO type. Bad news.

That's just my take on it anyway. Maybe what you have in mind is a lot cleaner? I just envision seeing a load more keywords being brought in that must be learned and kept track of.

cbk1994 07-01-2011 08:36 PM
By "compatibility is not an issue" I mean that for the purpose of this exercise, don't worry about existing code. Essentially, pretend you can make the changes before any code has been written. This was more for fun than to generate useful ideas for changes to be made now. Adding a strict class system on top of GScript now would be stupid.

MrDunne 07-01-2011 08:46 PM
Quote:
Originally Posted by cbk1994 (Post 1656958)
By "compatibility is not an issue" I mean that for the purpose of this exercise, don't worry about existing code. Essentially, pretend you can make the changes before any code has been written. This was more for fun than to generate useful ideas for changes to be made now. Adding a strict class system on top of GScript now would be stupid.
Oh so this is a basically "take GScript in your own way" sort of thing? Open up the VM and allow someone to write new languages on it. This is wishful thinking you. You'd need someone with the aptitude to do this (that's without taking into the "**** OFF" you'll get from the admin into consideration.)


All times are GMT +2. The time now is 08:56 PM.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2025, vBulletin Solutions Inc.
Copyright (C) 1998-2019 Toonslab All Rights Reserved.