Static variables

[xXziroXx]

Originally Posted by Inverness

Says the person who only knows GScript.

Quite wrong.

Also, very well said Skyld!

[Loriel]

Originally Posted by xXziroXx

Quite wrong.

Also, very well said Skyld!

Way to latch on to Skyld's post to defend your substance-less ****posting

[Inverness]

Well all the more reason to have private variables. I don't think actual static function variables would work to well with the way GScript is right now.

And another thought, there isn't really a way to list global variables, so it would be possible to hide some value as a global variable assuming noone else can see the script. Though I think doing that would be a bit funky.

Originally Posted by Skyld

WILL NOT HAPPEN.

Now that we've cleared that up, please move on with your life.

Don't raise your voice at me young man.

Originally Posted by xXziroXx

Quite wrong.

Also, very well said Skyld!

Loriel put it better than I could have.

[Admins]

Actually you can display global variables now with /memstats full.

I didn't want discussion about lua or so because it's more philosophical, better to open a new thread for speaking about what stuff graal script should borrow from other languages or so.

[Pelikano]

Isn't LUA harder?

Note: I don't know anything about LUA, but since it's used in WoW it should be a little harder than a language for a 2D game oO
And isn't LUA only used to do visual stuff?

Ah crap, someone tell me what LUA is all about :f

[Loriel]

Originally Posted by Pelikano

Isn't LUA harder?

Note: I don't know anything about LUA, but since it's used in *** it should be a little harder than a language for a 2D game oO
And isn't LUA only used to do visual stuff?

Ah crap, someone tell me what LUA is all about :f

no it is actually easier

Lua is a language specifically designed to be easy to pick up and to be embedded into applications. It has nothing to do with "visual stuff", but since the entire point of a programming language is to do new stuff with it, it does not have to. Blizzard did not write their 3d engine in lua, they just embedded the lua runtime into their (C++) application and defined a huge number of additional functions that lua code can use to interact with the user interface. That has obviously no effect on the language itself.

At the danger of risking Stefan's wrath: I think the lua language and compilation model is easier to understand than gs2. There are fewer concepts you need to grasp in order to reason about the behaviour of a lua program because there is plain less magic going on, and there is a small number of language features that are extremely powerful (thinking of lexical closures for all kinds of crazy functional programming things, and composing arbitrary data structures from simple tables). Of course, this might as well be a downside to the whole thing, since the parts of gs2 that are more complicated are mostly that way because Graal's game world is directly integrated with the gs2 "object space"

The thing that sold me on lua is that there is a single reference manual that explains absolutely everything that is in the language, and is relatively easy to read and comprehend.

[Inverness]

Originally Posted by Stefan

Actually you can display global variables now with /memstats full.

I didn't want discussion about lua or so because it's more philosophical, better to open a new thread for speaking about what stuff graal script should borrow from other languages or so.

Oh dear, there are so many more global variables than I thought. There is also alot of uknown_object. Stefan could you change it so unknown_objet is simply not added to global variables?

By the way, I've also wondered if global variables and object variables are stored using hash tables?

[Admins]

Lua is much much simplier than languages like Graal Script, Flash etc., and is easier to optimize. However there are few things that make it not good for our use: the syntax is very different to C/C++/Java/JavaScript/Flash/Graal Script, and of course most Graal stuff is not existing or at least not in the extend we are using them (join/leave classes, sleep/waitfor, variable scope, dynamic allocation of variables, automatic event binding etc. etc.). So it's quite interesting, but not a drop-in replacement. If we ever switch to another language or system then only for speed (e.g. a just-in-time compiler which exist for all platforms, including iphone, llvm might be the light at the end of the tunnel) or for better compatibility with code from other platforms, including Flash and Java programs.

All variables are stored in hash tables yes.
"unknown_object"s are mainly GUI objects or so which don't have a name. They still exist in the global variable space though.

[Inverness]

Originally Posted by Stefan

Lua is much much simplier than languages like Graal Script, Flash etc., and is easier to optimize. However there are few things that make it not good for our use: the syntax is very different to C/C++/Java/JavaScript/Flash/Graal Script, and of course most Graal stuff is not existing or at least not in the extend we are using them (join/leave classes, sleep/waitfor, variable scope, dynamic allocation of variables, automatic event binding etc. etc.). So it's quite interesting, but not a drop-in replacement. If we ever switch to another language or system then only for speed (e.g. a just-in-time compiler which exist for all platforms, including iphone, llvm might be the light at the end of the tunnel) or for better compatibility with code from other platforms, including Flash and Java programs.

I think a GScript's problem is consistency. It has alot of quirks like I dislike:

• Dynamic variables are case-sensitive, yet static variables aren't.
• Object-oriented design, yet lack of actual user-defined classes.
• A whole range of global variables and functions, yet an inability to create your own.

I think we need a GS3 which is a more refined an object-oriented version of GS2, with full support for classes and stuff like that. For example, providing a script for a weapon should involve subclassing the weapon class and overriding the event functions in the weapon class.

Originally Posted by Stefan

All variables are stored in hash tables yes.
"unknown_object"s are mainly GUI objects or so which don't have a name. They still exist in the global variable space though.

[Loriel]

Originally Posted by Inverness

For example, providing a script for a weapon should involve subclassing the weapon class and overriding the event functions in the weapon class.

Can we just pretend it actually does this already?

[Codein]

Originally Posted by Inverness

I think a GScript's problem is consistency. It has alot of quirks like I dislike:

• Dynamic variables are case-sensitive, yet static variables aren't.
• Object-oriented design, yet lack of actual user-defined classes.
• A whole range of global variables and functions, yet an inability to create your own.

I think we need a GS3 which is a more refined an object-oriented version of GS2, with full support for classes and stuff like that. For example, providing a script for a weapon should involve subclassing the weapon class and overriding the event functions in the weapon class.

Agreed.

[Inverness]

Originally Posted by Loriel

Can we just pretend it actually does this already?

[Admins]

Graal uses a more dynamic class system instead of a compiler-based class system, those things cannot be mixed easily. Graal demands objects to be dynamic, you can create and modify the objects at any time.

On the other side you have languages like C++ and Java which are basicly providing a class system which restricts the programming to a certain set of class functionality which are only useful at compile-time. When the program is compiled and running then the "class" system is just a chunk of memory and a list of functions attached to each object. These are quite different concepts.

See the idea of "static" variables: it is a restriction, you are basicly using global variables but when compiling the script the compiler ensures that you can only access it from a certain piece of code. The variable is however still accessible from the other code, with some tricks.

[Inverness]

Originally Posted by Stefan

Graal uses a more dynamic class system instead of a compiler-based class system, those things cannot be mixed easily. Graal demands objects to be dynamic, you can create and modify the objects at any time.

Perhaps you should use Python as a reference for how you would want to improve GScript, it has a dynamic class system where classes (types) can be created dynamically and objects can optionally have dynamic variables using a hash table. The same type objects are used for static (built-in) types as with dynamic types.

I'm a person who dislikes reinventing the wheel, which is why I always make suggestions about using Python, because I think while it make take alot of effort (binding using Boost.Python, applying security changes to Python source, converting scripts) to convert in the short term, it would be better for the longevity of Graal if you want Graal to continue for years to come.

[Loriel]

Originally Posted by Inverness

I'm a person who dislikes reinventing the wheel, which is why I always make suggestions about using Python, because I think while it make take alot of effort (binding using Boost.Python, applying security changes to Python source, converting scripts) to convert in the short term, it would be better for the longevity of Graal if you want Graal to continue for years to come.

I think the Wesnoth guys came to the conclusion that they could not safely run arbitrary python scripts in their game client because it could not be made secure.