ZDoom

[quote=Xeotroid post_id=1247914 time=1701283911 user_id=7273]
Can they/Are they planned to be used with associative maps too?
[/quote]

I haven't reviewed the code or anything. I just know they exist now. Presumably they can do anything that a normal static function can do.

[quote=Marrub post_id=1247913 time=1701282834 user_id=8265]
Function pointers—currently in GZDoom dev builds—
[/quote]
WHAT?? :shock: I had no idea.
[size=70]Can they/Are they planned to be used with associative maps too?[/size]

I've got a lot of duplicated code in Lithium that would probably be significantly easier to handle with interfaces, stuff that wouldn't do with mixin. Function pointers—currently in GZDoom dev builds—probably will help many of them, but a way of doing vtables independent of the actual class hierarchy would be incredible. On the other hand, this does seem like a lot of effort to implement. You'd probably have to touch a lot of the weird class internals that don't get touched much. To me, it seems worth it.

Interfaces would indeed be very useful. If you're making fairly standard/basic mods, sure, you won't need them, but the moment you want to make something complex or want better, more structured, and more future-proof submod support, you really start to miss interfaces.

No idea why anyone would expect mixins to fill in for interfaces, they're more like C#'s default interface implementations. (and that's one of their main purposes in D, where they came from)

Mixins fall flat on their ass the moment you have to use them outside the archive. They also can't be type-checked for obvious reasons so if you have a base weapon class and a base item class, both implementing the same mixin, you have to riddle everything with typecasts to make sure you're operating on the right type of item. You can't just do "if X is IExtendedItem" or "let item = IExtendedItem(x)" and access something that's specific to the interface, regardless of whether or not the item's parent is Weapon or Inventory or some other non-Weapon Inventory-derived type. Interfaces would be an absolute godsend for mods that implement a framework for addons to use, but even internally they'd be great. Right now I have to do some features through [url=https://gitlab.com/accensi/deathstrider/-/blob/master/ZScript/Components/MovementAi.zsc]Thinker-based components.[/url] With interfaces I could do it on the class directly instead of being forced to work in super abstract terms, as components by their nature need to be user-agnostic. Plus I can actually check if a given actor even implements an interface. Right now I can't really iterate all monsters and get only the ones that have MovementAI, or get all spellcasters that have an [url=https://gitlab.com/accensi/deathstrider/-/blob/master/ZScript/Components/Arcanum.zsc?ref_type=heads]Arcanum[/url] component. That's just one of the many examples I've encountered over the last few years. There are plenty others. Mixins sorta kinda work but they're subpar at best. Code becomes somewhat cleaner if you use them right, but they ultimately have more drawbacks than benefits.

In other words, the lack of interfaces in ZScript becomes really noticeable and genuinely frustrating if you do things the right way and with moddability in mind.

Interfaces are like using Vulkan instead of OpenGL. It takes more work, but allows finer control. Instead of inheriting one primary class, then another class which may have tons of stuff you don't need and may even conflict, the other class would be defined as a set of contracts; sometimes with an associated class that can be used as an engine under the hood for implementing default versions of some of them. It's a saner way to do multiple inheritance.

That said, although I've defined and used interfaces extensively in .NET, I've not encountered anything in ZScript that truly required interfaces and couldn't be done with mixins. Though who's to say that somebody won't some day :twisted:

In C++ which has multiple inheritance in general, abstract classes are used, so there is no practical difference there. In languages without multiple inheritance (for good reason, imo, imagine someone trying to do something like [c]class SuperMonster : DoomImp, ZombieMan[/c]), multiple interfaces can still be used. The common way to describe them is a "contract" - they have absolutely no implementation of their own[b]*[/b], they just specify method signatures, all of which [b]must[/b] be implemented by the classes that use those interfaces.

Taking C# as example, one common interface is IComparable<T>, which, when used and implemented in a class, lets you call the CompareTo() method (declared by the interface, defined by the implementation) for sorting purposes, or IDisposable, which is used by [c]using[/c] blocks for automatic clean-up of unmanaged resources after leaving scope. A class can "inherit" from both of them in addition to one actual inheritance, but really it's less of an inheritance and more of a promise to implement CompareTo(T other) and Dispose().

In ZScript, I can imagine more complex mods could utilise this for more navigable code that's less of a spiderweb of inheritances. I myself with my frankly horrible un-navigable code practices might opt to ignore interfaces like I often do in C#, but more skilled programmers might welcome them.

*Let's not get into the shenanigans C# has like default implementations...

How are they different from abstract and why do you need them? What problem do you have without them and how do they address it?

I wonder if adding [url=https://en.wikipedia.org/wiki/Interface_(object-oriented_programming)]interfaces[/url] to ZScript would be considered a good idea: There already are abstract classes and methods, so interfaces don't seem far fetched (and definitely a better idea than suggesting multiple inheritance in general). Syntax-wise, there could just be a new [c]interface[/c] keyword for classes like [c]abstract[/c] or [c]mixin[/c], and a multiple of comma-separated class names could be specified when inheriting.