AGS Easy Plugin (v0.8a): Create a full engine plugin in one click-TESTERS NEEDED

Started by Monsieur OUXX, Mon 18/06/2012 02:40:35

Previous topic - Next topic

monkey0506

Well the C++ classes themselves would be the backing data, so for a plugin I wouldn't even define those. I'd only define them if I was writing code using attributes in native AGScript (which I do all the time, all of my most recent modules rely on them). So in reality, I wouldn't expect to see those "extra" properties in the file being fed into your exporter (and wouldn't worry about handling it as a special case).

Edit: Hey, if nothing else this is a good place for me to dump some of the information I've learned about the engine's capabilities that 99% of other users know nothing about (and even CJ himself has been surprised by some of). ;D

Monsieur OUXX

Quote from: monkey_05_06 on Thu 21/06/2012 22:44:46
Hey, if nothing else this is a good place for me to dump some of the information I've learned about the engine's capabilities that 99% of other users know nothing about (and even CJ himself has been surprised by some of). ;D

Yes, that's why I was trying to make you spit it out :) I've noticed you know all the tricks about AGS scripting language, that drive me crazy every time because I have to re-learn them by trial-and-error after each 6-months break in AGS programming, when I've forgotten it all.

What do you think about that "Create" thing? There can be a Create function only for the base class, so I'm not sure how to implement constructors for the children. I'll go with creating constructors with different names for each child class, but my senses tingle, there's got to be another way...
 

monkey0506

Well you actually got me really hoping that I would be able to override static methods, but no such luck. Because the original method would be static, but then the extender method overriding it would be non-static, you can't call it statically. Presumably if we had static extender methods then this would be possible.

By the way, in order for the polymorphic override to work (not just compile, but actually be called) it has to be in a separate script from where the original function definition is at (see, I learn new stuff all the time).

Having to cast the pointer (read as: call the AsXXX property) every time you create a member of a derived class seems ridiculous, but for now I can't think of a better way to get around this than simply having differently named constructors. Perhaps the exporter should (for the time being) generate constructors such as "Class.CreateClass" rather than just "Class.Create". It does seem redundant, but this is probably the best we've got (for now).

Monsieur OUXX

Quote from: monkey_05_06 on Fri 22/06/2012 18:45:36
Perhaps the exporter should (for the time being) generate constructors such as "Class.CreateClass" rather than just "Class.Create". It does seem redundant, but this is probably the best we've got (for now).

Yes, that's the naming "convention" I was going to adopt in case I'm going that way.
Now I have to find the motivation to do all the scripts tests to be 200% sure of what works and what doesn't, regarding extenders overriding/overloading :-) :-( :-) :-(

 

Monsieur OUXX

Quote from: monkey_05_06 on Thu 21/06/2012 17:26:43
Quote from: Monsieur OUXX on Thu 21/06/2012 15:31:52
Code: ags
//Imagine this:
Point2D* p = Point3D.Create();
p.foo(66); //it calls the code of "float foo(this Point3D*, int newParam)"
p.foo(); // what happens? Was "Point2D::foo()" definitely overridden by the extender, even with this prototype, or only overloaded?

//if I declared "foo2(this Point3D*, int newParam)":
p.foo2(); //what would this do? Was "int foo2(this Point2D*)" only overloaded by "foo2(this Point3D*, int newParam)", or completely overridden?


Interesting points, I don't think I actually fully tested them, but my gut instinct would be that they have been completely overridden and the parameterless methods would in this case be inaccessible.
One note though, you cast the Point3D into a Point2D pointer. In AGS this means that the base class functions would be called, not the derived class functions (again, this is something that goes against true polymorphism, but CJ never intended this behavior to begin with :P).

OK, part from the fact that this is giving me a headache, I just wanted to mention that I tested the code above (Not with a pointer obtained via Point3D.Create(), though, but instead with "Point3D p;" for the time being).
the Point2D versions of the functions are indeed entirely replaced. The AGS compiler forbids the call to "p.foo();" AND to "p.foo2();". In both cases, the parameter-less version is gone.
 

monkey0506

To be honest, that's exactly what I expected. I just wasn't sure that I had personally tested those specific cases.

Monsieur OUXX

Quote from: monkey_05_06 on Thu 21/06/2012 17:26:43
One note though, you cast the Point3D into a Point2D pointer. In AGS this means that the base class functions would be called, not the derived class functions

I wonder what happens with this :
Code: ags

Point2D* p2d = Point3D.Create();
Point3D* p3d = p2d;
p3d.foo();

It will call Point3D::foo() I suppose (I'll double-check later today). So, it always calls the function defined in the apparent type, doesn't it?
 

monkey0506

Quote from: Monsieur OUXX on Tue 26/06/2012 09:20:05
Code: ags
Point2D* p2d = Point3D.Create();
Point3D* p3d = p2d;
p3d.foo();

That doesn't make any sense. The line:

Code: ags
Point3D* p3d = p2d;


Is invalid. AGS doesn't allow casting to derived-type pointers. Hence the need for the AsPoint3D property (which for the record *I* suggested, in my original code snippet :P). And yes, AGS always calls/links functions based on the calling ("apparent") type, not necessarily the underlying object type (which I have noted as a regression against true polymorphism, but, as I noted before, also provides the only way to call base class methods, at least until proper polymorphism can be implemented).

Monsieur OUXX

Quote from: monkey_05_06 on Tue 26/06/2012 15:12:56
That doesn't make any sense. The line "Point3D* p3d = p2d;" is invalid because AGS doesn't allow casting to derived-type pointers. Hence the need for the AsPoint3D property.
Yeah, yeah, you got the idea; that was just a quick example of switching back to Point3D* to make the apparent type match the real type.
 

SMF spam blocked by CleanTalk