Graal Forums - Support for various operations

Graal Forums (https://forums.graalonline.com/forums/index.php)

- Future Improvements (https://forums.graalonline.com/forums/forumdisplay.php?f=10)

- - Support for various operations (https://forums.graalonline.com/forums/showthread.php?t=72441)

Support for various operations

I've always wondered why these 5 words were highlighted in my code when they do nothing:

PHP Code:


		
			
import

extends

class

package

implements

I know they can be used in Java, somewhat like this:

PHP Code:


		
			
package myPack;



import myPack.oneClass;

import myPack.anotherClass;



public class Whatever extends This implements That

{

     oneClass.go();

}

Is there to be any support for these commands in the future?

Definitions for each commands

Package
The package command in Java imports a folder that contains classes, example: myPack.thisClass in the folder would be myPack/thisClass.

Import
Same as this.join, except it imports only the functions and not the variables (except for integers, such as CLOSE_ON_HIDE, on that line)

Extends
This is virtually the same as this.join.

Class
Self-Explanitory. This just defines the file as a class, and you can put many of these in a file to specify more than one class. E.g.:

PHP Code:


		
			
public class this

{

     // Some code

}



public class this_whatever

{

     // Some code



}

This can be useful if you don't want to spam your class list.

Implements
About the same as import, but all variables are imported into the current class.

Any ideas/comments?
* NO FLAMING OR WHATEVER! *

Those functions are highlighted in the RC because I have copied & modified the syntax highlight definitions from Java, you can modify the definition, it's put somewhere in the user directory.
Graal uses a different, more dynamic way of classes which you can join and leave at any time. I am not sure if those two ways can easily be combined, although it could be interesting to add more functionality if it's helping for coding.

In the next Graal version the support for using classes on client-side is much better, so you can use onCreated() (plus caching of classes and when you call a function of an object which is waiting for classes to be downloaded then it is suspending the script until the classes have been downloaded)

I would like to see something like 'import' being made functional by allowing you to create function links in one object to another.
Example:

Weapon: +Strange/Name
public function a()
public function b()

Weapon: +Another/One
public function a()
public function c()

So you have function a() and b() in the weapon +Strange/Name which due to the characters in it, you can't call +Strange/Name.a() and such because of the special characters so you have to use makevar() or something.

Now in the weapon named +Another/One you could have something like:
function onCreated() {
import(makevar("+Strange/Name"));
}

What the import function would do would be to take an object as its parameter and make function links in the current object leading to the imported object. This way you can call functions from other objects without using large object identifiers before the function.

Also, you might notice how function a exists in both objects, I think there could be an option in the import function to overwrite existing functions with imported ones or not. Also importing would only work for public functions since its basically inserting one function linking to another.

Again, maybe another feature could be an import prefix, which would simply add the specified prefix to imported function names so existing functions can't be overwritten at all.

Quote:

Originally Posted by Stefan (Post 1281879)

Oh cool, I'm going to edit mine! :p

Quote:

Originally Posted by Inverness (Post 1281938)

I would like to see something like 'import' being made functional by allowing you to create function links in one object to another.

Would be ("+Strange/Name").a()
Theoretically such an "import" function is possible since weapon and npc scripts can work as classes too, it might be a little bit confusing though and might be better to put the code into an own class and then join it from both objects

Eh, its not better in my case where the code requires serverside/clientside communication, best done by weapon.

I personally think it would be great to include, especially imports:

PHP Code:


		
			
import battlesystem;



(serverside code)



//#CLIENTSIDE

(clientside code)

I would like to see Import work on both sides, serverside and clientside.