Define your own variable types

[Tolnaftate2004]

PHP Code:

function varType(argsv[]) {
  with (new TStaticVar()) {
    /* public: */
    this.varType = function () {

    };

    /* definitions */

    if (this.varType != NULL)
      this.varType();

    return this;
  }
} 


This is a pretty bare-bones C++-style "class". The function I've defined is the constructor. Have fun, and maybe Inver will stop complaining. :P Also, argsv[] is just a placeholder (typically seen in C) for any sorts of parameters you'd want to pass to these "classes".

[Chompy]

Really, really nice

[Inverness]

I'm confused, what is that supposed to be doing? Why are you defining varType as an array then calling it as a function? And what does this have to do with Object Types?

[Tolnaftate2004]

Originally Posted by Inverness

I'm confused, what is that supposed to be doing?

Define whatever members/methods you want inside, and...

PHP Code:

temp.myVar = varType(argsv); 


[killerogue]

I still, pretty much have no clue, what you're talking about PFA.

[Inverness]

This has nothing to do with custom object types. Stop trying to be cool -.-

You have no idea what I'm talking about.

[Tolnaftate2004]

e.g.,

PHP Code:

function varType(strName) {
  with (new TStaticVar()) {
    /* public: */
    this.varType = function () {

    };
    this.tname = strName;
    /* definitions */

    if (this.varType != NULL)
      this.varType();

    return this;
  }
}

function onCreated() {
  temp.myvar = varType("Jack");
  echo(temp.myvar.tname);
} 


Originally Posted by Inverness

This has nothing to do with custom object types. Stop trying to be cool -.-

You have no idea what I'm talking about.

This is exactly how you make custom object types in JavaScript.
So tell me, what do you want? Something wrapped in a useless macro?

And the array thing I typed up real fast and didn't catch until after I posted.

[Inverness]

I take that back, interesting, but no cigar. Offers no form of inheritance or any of the neat features of actual graal object types.

Heres my solution to the problem:

[Tolnaftate2004]

Originally Posted by Inverness

I take that back, interesting, but no cigar. Offers no form of inheritance or any of the neat features of actual graal object types.

Heres my solution to the problem:

There's no great reason to code inheritance since all object types inherit TGraalVar. Though it is possible.

e: Not to mention it doesn't have to be TStaticVar in the definition. You can use something more upper-level if you need specific inheritance.

[Inverness]

Does your mind exist in Candy-Land or something? x-x

Originally Posted by Tolnaftate2004

There's no great reason to code inheritance since all object types inherit TGraalVar. Though it is possible.

You can't even edit TGraalVar, so yes I code inheritance so I can update the base class and add support for features to its subclasses automatically.

Originally Posted by Tolnaftate2004

e: Not to mention it doesn't have to be TStaticVar in the dfinition. You can use something more upper-level if you need specific inheritance.

Um, yes it does have to be TStaticVar, there are no other blank object types.

[Tolnaftate2004]

Originally Posted by Inverness

Does your mind exist in Candy-Land or something? x-x

Most of the time.

Originally Posted by Inverness

You can't even edit TGraalVar, so yes I code inheritance so I can update the base class and add support for features to its subclasses automatically.

You can make one a child of TStaticVar or whatever and make another a child of your custom type...

Originally Posted by Inverness

Um, yes it does have to be TStaticVar, there are no other blank object types.

You can use TGraalVar(), any GUI control, etc., as long as there is no name (except TShowImg and maybe some others...), and you'll have made an anonymous variable of that type.

[Inverness]

Originally Posted by Tolnaftate2004

You can make one a child of TStaticVar or whatever and make another a child of your custom type...

No you can't, you can only copy variables that way not functions, using: ObjectVar = new ExistingObject("NewName");, unless joinedclasses suddenly became writable. If joinedclasses is writable and noone told me I'm going to explode.

Originally Posted by Tolnaftate2004

You can use TGraalVar(), any GUI control, etc., as long as there is no name (except TShowImg and maybe some others...).

Why would I want to do that? It limits the amount of variables I can use without conflicting with the static variables of non-blank object types.

Edit: I just tested, apparently joinedclasses can be written now, my rage is insurmountable. Oh well, my system is still superior.

[Kristi]

Tol made a good contribution. Can someone point out to me why it was neccessary to start a big argument with name calling? By someone, perhaps Inverness is best suited to answer.

It is just this over and over on these forums anymore...

[zokemon]

Originally Posted by Kristi

Tol made a good contribution. Can someone point out to me why it was neccessary to start a big argument with name calling? By someone, perhaps Inverness is best suited to answer.

It is just this over and over on these forums anymore...

Agreed. Inverness found out his accusations were wrong, I think an apology is in order.

[Inverness]

Here is a little something I whipped together after my recent discovery.

PHP Code:

function onCreated() {
  this.types = null;
  // X System
  maketype("XObject", null, {"util_triggerall", "type_xobject"});
  maketype("XTestObject", TXObject, {"type_xtestobject"});
  // Mud
  maketype("XMudObject", TXObject, {"type_xmudobject"});
  maketype("XMudItem", TXMudObject, {"type_xmuditem"});
  maketype("XMudContainer", TXMudObject, {"type_xmudcontainer"});
  maketype("XMudPlayer", TXMudContainer, {"type_xmudplayer"});
  // Misc
  maketype("Rectangle", null, {"type_rectangle"});
  maketype("Vector", null, {"type_vector"});
}
public function maketype(typename, super, classes) {
  temp.i = 0;
  
  if ((@"T"@typename) != null) {
    (@"T"@typename).destroy();
  }
  this.(@ "type_" @ typename) = new TStaticVar("T"@typename);
  if (super.type() == 2) {
    this.(@ "type_" @ typename).joinedclasses = super.joinedclasses;
  }
  for (i: classes) {
    this.(@ "type_" @ typename).join(i);
  }
  if (this.types.index("T"@typename) < 0) {
    this.types.add("T"@typename);
  }
} 


Originally Posted by Kristi

Tol made a good contribution. Can someone point out to me why it was neccessary to start a big argument with name calling? By someone, perhaps Inverness is best suited to answer.

It is just this over and over on these forums anymore...

Arguments make things interesting to myself. Also I hope you noted the fact that he mentioned my name first in his initial post. As far as I'm concerned that gives me the right to counter, I don't appreciate your accusations. Also, I assume that hes saying that his script is a suitable replacement for the custom object types that I've mentioned many times before and however much I like the script it is certainly not what I want.

Originally Posted by zokemon

Agreed. Inverness found out his accusations were wrong, I think an apology is in order.

Please point out the 'accusations' you speak of. Also don't overlook "I take it back" this time.

[Tolnaftate2004]

Originally Posted by Inverness

Here is a little something I whipped together after my recent discovery.

Lovely.

I find this to work too:

PHP Code:

function varType(strName) {
  with (new TStaticVar()) {
    this.join("varType");
    this.aname = strName;
    return this;
  }
}
function varType2(strName) {
  with (varType(strName)) {
    this.join("varType2");
    return this;
  }
} 


Which solves the inheritance problems and retains the var = type() construction.

[zokemon]

Originally Posted by Tolnaftate2004

Lovely.

I find this to work too:

PHP Code:

function varType(strName) {
  with (new TStaticVar()) {
    this.join("varType");
    this.aname = strName;
    return this;
  }
}
function varType2(strName) {
  with (varType(strName)) {
    this.join("varType2");
    return this;
  }
} 


Which solves the inheritance problems and retains the var = type() construction.

I don't like how your class names and function names are the same.

[JkWhoSaysNi]

Interesting ideas. I can't seem to get it to work. I'm trying to implement function inheritance but I can't even get your example to work:

PHP Code:

function parent(strName) {
    with(obj = new TStaticVar()) {
    this.someFunction = function() {
        this.someVar = 4;
      };
  }
      return obj;
}


function child(strName) {
    with (parent(null)) {
    someFunction = function() {
        someFunction();
        this.someVar += 2;
        };
  return this;
    }
}
function onCreated() {
  test = parent("test");
  echo(test.getVarNames());
  echo(test.getFunctions());
  test.someFunction();
  echo(test.someVar);
} 


Here, test.getVarNames(); lists someFunction but getFunctions does not. When someFunction() is called an error appears in RC: Function unknown_object.someFunction not found at line 24 in script

Any ideas?

[killerogue]

Hm, you're looking for object inheritance right Knight? :O

[Chompy]

Originally Posted by JkWhoSaysNi

Interesting ideas. I can't seem to get it to work. I'm trying to implement function inheritance but I can't even get your example to work:

PHP Code:

function parent(strName) {
    with(obj = new TStaticVar()) {
    this.someFunction = function() {
        this.someVar = 4;
      };
  }
      return obj;
}


function child(strName) {
    with (parent(null)) {
    someFunction = function() {
        someFunction();
        this.someVar += 2;
        };
  return this;
    }
}
function onCreated() {
  test = parent("test");
  echo(test.getVarNames());
  echo(test.getFunctions());
  test.someFunction();
  echo(test.someVar);
} 


Here, test.getVarNames(); lists someFunction but getFunctions does not. When someFunction() is called an error appears in RC: Function unknown_object.someFunction not found at line 24 in script

Any ideas?

Try name the TStaticVar?

[JkWhoSaysNi]

didn't help. I can't get it to work at all.

[Inverness]

I don't know about function inheritence but class inheritence works fine because joinedclasses can be written directly, just use classes.

[JkWhoSaysNi]

Yes, i suppose it's possible

e.g.
parent class

PHP Code:

function aFunction() {
//do something;
} 


child class

PHP Code:

join("parent");
function aFunction() {
parent::aFunction();
//do something else
} 


[Tolnaftate2004]

Originally Posted by zokemon

I don't like how your class names and function names are the same.

They can be changed on a whim. I just like it that way for a psuedo-"class::method()" design.



And as for the function inheritance thing, I've been messing around with it too. Saving a function to a variable seems to give it a null value (try echo), so that's all you get when you try to copy it from something else. It still comes up in the var names, but it's just 0.

[Inverness]

I wouldn't use a function to return a custom object either, since function's cant be made global by anyone but Stefan. Using my method, it creates objects with the typical global name that can be used anywhere without the need for joining classes to access the functions and such.

PHP Code:

function onActionPlayerOnline() {
  MudControl.player_Inverness = new TXMudPlayer("MudPlayer_Inverness");
} 


Looks nicer like that too.

[JkWhoSaysNi]

Wow, i looked at your code on the previous page but couldn't really see what it did.

That is very nice Inverness.

I don't understand how it makes them usable anywhere though.

[killerogue]

TStaticVar's by nature are made global objects when you name them I believe.

[Inverness]

Originally Posted by killerogue

TStaticVar's by nature are made global objects when you name them I believe.

Graal is just automatically making a global variable that points to the object. Its not different than making a global variable to point to level npcs or to players. On Aeon when the player logs in I have makevar("Player" @ player.account) = player;This was originally added so I could access any player using makevar() with an old script.

The only problem I'm seeing with my method is that onCreated() is not called until after the function that is creating the object.

PHP Code:

function onCreated() {
  temp.v = new TVector();
  v.a = 5;
} 


In this, onCreated will be called in the new vector object after that function has finished.

PHP Code:

function onCreated() {
  temp.v = new TVector();
  sleep(0.1);
  v.a = 5;
} 


If you add in the sleep, onCreated is called in the object while the current function is sleeping, this is something I would like without the use of sleep.

Basically I'm requesting an event onJoinedClass or something that is called as soon as Graal joins the class script and before the next class is joined so I can execute functions that need to be done before continuing. If something like this already exists by all means point it out please

[JkWhoSaysNi]

I've updated your script so it calls things as you'd expect. Before onCreated was only getting called in the parent class, not both the parent then the child class.

Here:

PHP Code:

public function maketype(typename, super, classes) {
  temp.i = 0;
  
  if ((@"T"@typename) != null) {
    (@"T"@typename).destroy();
  }
  
  this.(@ "type_" @ typename) = (super.type() == 2) ? new super("T"@typename) : new TStaticVar("T"@typename);
  
  
  for (i: classes) {
    this.(@ "type_" @ typename).join(i);
    
  }

  
  if (this.types.index("T"@typename) < 0) {
    this.types.add("T"@typename);
  }
  
} 


I actually did this in an attempt to get function inheritance working, but I don't think that it's possible using this method because theres no way to know from what class in the original object to inherit from. You use parentobject.joinedclasses[0] but this wont work:

parent::function

where parent is a string variable because it expects a class name before ::.


edit:


Although that does the onCreateds in the right order, when you go to call a function on the object it will look for it in the parent class first. This is a problem, I don't think it's possible to have onCreated's in the correct order *and* have function calling work upwards.

So either: onCreated gets called in the child then the parent and functions get called in the parent when the same function name exists in both the parent and the child
or: onCreated gets called in the parent then the child (as you'd hope) and functions are looked for in the parent before the child.

[Inverness]

onCreated gets called in each joined class in the order that they're joined. The super variable in the function is just an object to copy class names from initially so you dont have to retype all the class names again in the area that calls maketype().

Function inheritance works fine like this, there is no reason to change the script.

Observe:

PHP Code:

function onCreated() {
  this.types = null;
  // X System
  maketype("XObject", null, {"util_triggerall", "type_xobject"});
  maketype("XTestObject", TXObject, {"type_xtestobject"});
  // Mud
  maketype("XMudObject", TXObject, {"type_xmudobject"});
  maketype("XMudItem", TXMudObject, {"type_xmuditem"});
  maketype("XMudContainer", TXMudObject, {"type_xmudcontainer"});
  maketype("XMudPlayer", TXMudContainer, {"type_xmudplayer"});
  // Misc
  maketype("Rectangle", null, {"type_rectangle"});
  maketype("Vector", null, {"type_vector"});
} 


And this.

PHP Code:

function onCreated() {
  this.types = null;
  // X System
  maketype("XObject", null, {"util_triggerall", "type_xobject"});
  maketype("XTestObject", null, {"util_triggerall", "type_xobject", "type_xtestobject"});
  // Mud
  maketype("XMudObject", null, {"util_triggerall", "type_xobject", "type_xmudobject"});
  maketype("XMudItem", null, {"util_triggerall", "type_xobject", "type_xmudobject", "type_xmuditem"});
  maketype("XMudContainer", null, {"util_triggerall", "type_xobject", "type_xmudobject", "type_xmudcontainer"});
  maketype("XMudPlayer", null, {"util_triggerall", "type_xobject", "type_xmudobject", "type_xmudcontainer", "type_xmudplayer"});
  // Misc
  maketype("Rectangle", null, {"type_rectangle"});
  maketype("Vector", null, {"type_vector"});
} 


Both of those scripts will do the same thing.

[JkWhoSaysNi]

By function inheritance I mean that when you call function() in a child, it's possible to also call it in the parent.

e.g.

function() is called.

function() calls parent::function()

[parent::function() calls grandparent::function()]

then whatever has to happen in function() occurs.

[Tolnaftate2004]

Originally Posted by JkWhoSaysNi

By function inheritance I mean that when you call function() in a child, it's possible to also call it in the parent.

Typically in OOP, this is not the desired effect. The parent function should only be called if the child does not have a function of the same name (should be a virtual function).

[JkWhoSaysNi]

Not true. In a lot of OO lanuguages in the child class you can choose to redefine (inherit) or override (no inheritance) or even in some languages, undefine the function.

E.g. in Eiffel (which probably has one of the best OO models going) to allow for real multiple inheritance you can choose to rename, redefine or undefine (or a few others iirc)
code example

PHP Code:

class
 child
inherit
 parent
  redefine functionName
end
feature 
 functionName 
  do 
    precursor --run the function of the same name in the parent
     --then do whatever
  end 


Similar functionality is available in Delphi.

[Tolnaftate2004]

Originally Posted by JkWhoSaysNi

rename, redefine or undefine

Okay, well perhaps I misunderstood, but none of these seem to be of real interest for graal datatypes joining classes.

[Inverness]

Inheritance in Graal doesn't work like that, you're not supposed to overwrite functions or variables. You're just supposed to extend the functionality of the supertype without changing it or complete its functionality if the supertype is abstract. If you observe the object type structure on the Wiki you'd notice that functions and variables are never overwritten by subtypes.

An example of this is the TXMudContainer type on Aeon. Its abstract and gives all subtypes (most especially TXMudPlayer) the ability to hold items. This allows for easy moving of item objects between players, npcs, and containers in the world like barrels and crates.

One of the tools I find invaluable for modularity and object types is this function, triggerAll():

PHP Code:

public function triggerAll(eventname, param0, param1, param2, param3, param4, param5, param6, param7, param8, param9) {
  this.scriptlogmissingfunctions = false; // for no RC errors.
  
  temp.i = 0;
  temp.list = this.joinedclasses;
  
  list.remove("util_triggerall"); // Class with this script
  makevar(eventname @ "_base")(param0, param1, param2, param3, param4, param5, param6, param7, param8, param9);
  for (i = 0; i < list.size(); i ++) {
    makevar(eventname @ "_" @ list[i])(param0, param1, param2, param3, param4, param5, param6, param7, param8, param9);
  }
} 


I don't find the classname::functionname() syntax too reliable.