difference between 'extenders' and the usual way?

[Monsieur OUXX]

what's the difference between this :

Code: ags

function SayHello(this Character*) {
    this.Say("Hello");
}

and this :

Code: ags

struct EnhancedCharacter extends Character {
    import void SayHello();
}

void EnhancedCharacter::SayHello() {
    this.Say("Hello");
}

...Were extenders created only because at this time one can only pass real Character*s (or any other managed type) to functions?

[SSH]

The problem is that all your characters are of type Character, not of type EnhancedCharacter ...

[Pumaman]

Yes exactly, if you use your suggested alternate method, then this won't work:

player.SayHello();

because it's of type Character and not EnhancedCharacter. Therefore the whole point of extender methods is to allow you to inject extra methods into pre-existing classes.

[Monsieur OUXX]

Character is not of type EnhancedCharacter ...

--Waiting for real inheritance, where an EnhancedCharacter can be used anywhere a Character is expected  :

PS : I'll continue my AGSH module only if CJ swears on the Bible that he'll not add this feature in about one week*, just when I'm about to finish implementing it

*(after having made some unfair diversion declarations like "i actually spend all my time busy coding the Cuppy assistant", etc  )

[Pumaman]

--Waiting for real inheritance, where an EnhancedCharacter can be used anywhere a Character is expected  :

That's already implemented, and isn't the problem.

The problem is that all the predefined Characters, such as cEgo, cBman, etc, are defined as being of type Character. If you create your EnhancedCharacter class, how do you intend to create a character that implements it?

[monkey0506]

...Were extenders created only because at this time one can only pass real Character*s (or any other managed type) to functions?

You do know that with an extender method you do not pass the Character* to the function, right? An extender method actually extends previously created types with new functions. As Chris said, if you define a SayHello extender method for the Character type:

Code: ags

function SayHello(this Character*) {
  this.Say("Hello");
  }

Then you call it on an instance of the character struct like this:

Code: ags

player.SayHello();

You do not call the function and pass a Character* as a parameter.

--Waiting for real inheritance, where an EnhancedCharacter can be used anywhere a Character is expected  :

That's not what inheritance is. That's polymorphism. AGS supports inheritance, just not polymorphism.

Which brings up another interesting point. The fact that you keep insisting that AGS isn't OOP. A lot of AGS's functions have been ported to OOP functions, and we can also implement our own OOP data types and functions. We can't have pointers to our own custom types, but that doesn't mean we can't use OOP. Using a struct within your code is OOP. Because you then call functions/properties of that object. Your programming becomes object-oriented. OOP doesn't mean the ability to define pointers to custom data types.

Also, extending a built-in type in the manner you've shown would be completely useless for precisely the reason Chris stated. You wouldn't be able to create characters that implemented this class. If you really wanted to use a custom class, you could import attributes for each property, in addition to importing all the functions, add a [write]protected Character* to link it to a real Character, and then set the get/set functions for the attributes to work with the associated properties of the Character and redirect the function calls through the Character's functions. Then you could create an array of your custom type with the size of AGS_MAX_CHARACTERS (or using a dynamic array Game.CharacterCount with the latest 2.8 betas), then call a custom function to set the internal Character* to the real AGS Characters. Then once you've fully emulated the Character class you can import your own functions...

Or...

You can use an extender method.

[Monsieur OUXX]

That's not what inheritance is. That's polymorphism.

Yeah, yeah, that's true. the word is wrong, but you got the idea.

Seems like I bring a lot of hostility here. Don't get confused, everytime i sound arrogant, it's just because i don't speak English well enough to smooth my sentences. Please, don't quote everything I say to demonstrate me that the script in its actual state is fully OOP. It's not true, you know it. It's almost OK, but yet it's somewhere in the middle. I'm not writing this to criticize, or anything like this. I'm just more and more wondering if the lot of time I spend in coding the "required" enhancements is worth it, because everything I implement gets implemented just the day after... I am NOT criticizing. This tool is amazing, and the script is very powerful. I'm just trying to unleash the 2% of features that still could be unleashed.

[Pumaman]

You're completely correct that AGS script is not a proper object-oriented language. It's a bit like C++, in that it started with a completely procedural language and has gradually evolved to add support for various OO things -- but currently it's only half-way there. For a game scripting language, I'm not even sure if full OO would necessarily be useful.

I'll continue my AGSH module only if CJ swears on the Bible that he'll not add this feature in about one week*, just when I'm about to finish implementing it

Hehe don't worry, I have no plans to do anything else to the script compiler (except perhaps support for dynamic arrays in structs) for 2.8.

[Monsieur OUXX]

Thanks

You're completely correct that AGS script is not a proper object-oriented language.

Forget about all I wrote about that. It's not a problem at all: i just dealt with this topic because I've been working a lot on this lately.
I think the only disturbing thing in the script is the fact that one can not have a struct as a member of another struct, and that one cannot pass a struct instance to a function. That's all. The rest would only be an extra.

[monkey0506]

I didn't mean to sound hostile myself, I was simply trying to point out that some of your terminology is incorrect which could lead to a lot of confusion as to what you're talking about.

Also I didn't mean to say that AGS is fully OOP, but you have seemed to go off on that point quite a bit which is why I wanted to state that AGS does support some OOP.

As for structs within structs, and structs as function parameters, I've heard it said before and I have to agree that pointers to custom structs is what we really need. If we could have pointers to custom structs then (ideally) we could have one of these pointers within another custom struct, emulating struct-within-struct support, and we could also pass them as function parameters. One of the major problems (I believe) with pointers to custom structs though is that of memory management. AGS is a highly managed program and does quite well to ensure that any memory it allocates is released. However allowing pointers to custom structs would make this more difficult. Hopefully Chris will find a way to implement it, but understand that you're not the first who has said they would find it useful.