[No] Mixins

Moderators: Developers, ZDoom.org Team

Mixins

Postby argv » Tue Sep 12, 2017 2:56 pm

Adding support for mixins (and/or multiple class inheritance) would help greatly in reducing boilerplate.

Consider, for example, a “mixin Reloadable : Weapon” that, when mixed into “class ReloadablePistol : Pistol, Reloadable”, adds a field to count the loaded ammo, an action that reloads the weapon, and a method that checks if reloading is currently possible. Without mixins (or some form of multiple inheritance), this involves a pile of boilerplate and static methods.

Of course, the VM will need to handle the case of inheriting more than one member with the same name. The worst of C++'s diamond problems shouldn't happen, though, since ZScript has neither constructors/destructors nor private inheritance.
argv
 
Joined: 30 Aug 2016

Re: Mixins

Postby Nash » Tue Sep 12, 2017 5:50 pm

Holy crap yes! This would be 100000% useful for me!
User avatar
Nash
Nash Muhandes [Audio Engineer | Game Designer | Scripting]
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia

Re: Mixins

Postby Graf Zahl » Wed Sep 13, 2017 2:14 am

This is wayyyyy beyond the engine's capabilities.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Mixins

Postby argv » Thu Sep 14, 2017 12:29 am

I was afraid you'd say something like that. :(

How about allowing “extend” blocks apply to more than one class at a time? That would have a similar effect to mixins, though it would of course only work within the same module.

I wish I had the time and skill to just replace ZScript with a scripting engine that already has all the bells and whistles. I have an idea of how to pull off extending/overriding C++ classes/methods from a non-C++ language (IIRC that was the big concern), and scripting ZDoom with the Java VM would be especially glorious, but it'd also be a medium-sized mountain of work. Not only would the integration be a project, but there's also the matter of translating ZScript/Decorate/ACS/DeHackEd/FraggleScript/whatnot to JVM bytecode at run time. That's a lot of compilers to write, and I've never written one! Meanwhile, I have a small family business that would fold very quickly without me.

Anybody feel like giving me a few million bucks so my family and I can retire and work on ZDoom instead? :D
argv
 
Joined: 30 Aug 2016

Re: Mixins

Postby Graf Zahl » Thu Sep 14, 2017 5:07 am

Same problem: To access these mixed in fields, a lot of added logic is needed because their address is different in each class and the class system has no facilities to deal with that.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Mixins

Postby argv » Thu Sep 14, 2017 12:40 pm

That's odd, because extend can already be made to apply to multiple classes by hand: copy and paste the extend block for each affected class. I take it doing that under the hood (even as pure syntactic sugar) would be much harder?
argv
 
Joined: 30 Aug 2016

Re: Mixins

Postby Graf Zahl » Thu Sep 14, 2017 1:35 pm

'extends' has technical limitations. It needs to be in the same translation unit as the base definition because otherwise it is not possible to inherit from the class and still have fixed variable offsets.

If you try to extend a class in a different translation unit, the following will happen:

Original definition of baseclass is 1200 bytes long.
Class childclass1 inherits from baseclass and starts its own variables at offset 1200.
Translation unit 2 extends baseclass by 8 more bytes. What now? The newly added data clashes with childclass1!
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Mixins

Postby argv » Fri Sep 15, 2017 10:51 pm

'extends' has technical limitations. It needs to be in the same translation unit as the base definition because otherwise it is not possible to inherit from the class and still have fixed variable offsets.

According to the wiki, extends are allowed to appear in different source files, provided they are in the same module (wad/pk3/whatnot). Is that what you mean by “translation unit”? Is the wiki incorrect?

If you try to extend a class in a different translation unit, the following will happen:

Original definition of baseclass is 1200 bytes long.
Class childclass1 inherits from baseclass and starts its own variables at offset 1200.
Translation unit 2 extends baseclass by 8 more bytes. What now? The newly added data clashes with childclass1!

But the script compiler is compiling all available classes/extensions/mixins/whatnot all at once, isn't it? Doesn't it already know about every class/extension/mixin/whatever that will ever be loaded in that run of the game? If so, then doesn't it already know how much memory will be ultimately needed for each class' objects, even if an extension/mixin/whatnot in another translation unit alters them?

Or does it decide object layout for each translation unit separately? If so, why? I can see that being a problem if dynamic loading/linking/code generation is possible, but AFAIK, it isn't in ZScript.

By the way, I don't mean any offense by any of this. :) ZScript is what ACS should have been, and it's one hell of a step forward for the Doom community.
argv
 
Joined: 30 Aug 2016

Re: Mixins

Postby Graf Zahl » Sat Sep 16, 2017 12:42 am

argv wrote:But the script compiler is compiling all available classes/extensions/mixins/whatnot all at once, isn't it?


No, it isn't. What's more important: There's native classes where you simply cannot add anything because their native subclasses have a different layout. This surely blocks the 3 main bases: Actor, Inventory and Weapon.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Mixins

Postby argv » Sat Sep 16, 2017 11:31 pm

No, it isn't.

Any particular reason?

What's more important: There's native classes where you simply cannot add anything because their native subclasses have a different layout. This surely blocks the 3 main bases: Actor, Inventory and Weapon.

Being able to mix into/extend/multi-extend any class other than those three would still be a major improvement.

But, as you already said, that's way beyond the engine's capabilities. :shrug: I guess I can hope that someone will implement ZScript mixins with a preprocessor…
argv
 
Joined: 30 Aug 2016

Re: Mixins

Postby Rachael » Sun Sep 17, 2017 6:24 am

argv wrote:Any particular reason?

If it keeps going like this, this isn't going to go well.

The answer was very clearly no, and I think Graf did enough to explain why. At this point it feels like you're trying to get something just by grilling way more than necessary, or just by being more annoying than necessary, and neither of these are going to get what you want.
User avatar
Rachael
 
Joined: 13 Jan 2004


Return to Closed Feature Suggestions

Who is online

Users browsing this forum: No registered users and 1 guest