Optional Module Methods

What is the common method of determining whether or not a module has been implemented by an implementing struct, namely using methods that may/may not have been declared depending on whether or not the module was implemented.

I also have another question, let's say I have a struct. Let's say this struct is likely to be extended (almost like an abstract struct), though I want to also be able to use modules on the "super" struct, how likely is this to perform properly? I remember having some troubles with inheritance and module implementation, I'm not sure though - any feedback?

-------------------
Edit #1 (1:57AM)
It seems that modules implemented in the super-type work properly in structs that inherit the properties of that super-type. I remember having a problem with inheritance and AutoIndex though.

Modules are essentially textmacros, so any methods they implement will behave the same as if they were written in the struct manually.

I remember having problems with AutoIndex though which lead me to believe (I believe EarthFury said something about them not working smoothly together too) that they were not fully compatible. It seems like for the most part they are, perhaps I was doing something stupid which caused them to malfunction for me.

So then, the answer is a static if statement? I was using just a regular one, which would not compile.

The error it was giving me before was that "methodName is not of type that allows "." syntax."; I'm curious as to how the static if-statement bypasses this.

Static ifs are evaluated at compile time, if they evaluate to false the code inside them is not parsed, so you can't get an error on it. It's all in the documentation.

Oh, I see; I don't even have to put valid values into a static if-statement - that's nice to know.


This compiles perfectly fine despite THIS_IS_NOT_A_VARIABLE not even existing in any sense.

Yes, any non-existing value defaults to false. It is how static ifs can check for non-existent libraries in the first place. Of course, deliberately using an invalid value such as THIS_IS_NOT_A_VARIABLE kind of defeats the purpose of having an if statement in the first place.

Berb, something about modules ~ each module is going to have a *fixed* static-if setup, meaning that almost every static-if will be the same for each struct it is implemented in.

The only way I know of to have different static-if compile differences is to use what Anitarf said (methodname.exists). You can actually use this in a disgusting way to achieve configurable modules

I'm pretty sure you can use constant booleans in static ifs, no need to resort to such ugly .exists abuse.

In a module, a static-if that reaches for a boolean that isn't in its original library defaults false before struct implentation - the only workaround I've been able to find is methodname.exists

Perhaps this was a problem with an older version of JassHelper? I just used a private static constant boolean in a struct and then implemented a module containing a static if that checked that boolean: if the boolean was true, the contents of the static if were not removed in the outputwar3map.j. The module and the struct were in different libraries if you think that's important.

Zinc documentation states that static ifs are evaluated before modules, in that case it would make sense for values in the struct not to be recognised by the static if in the module; however, if that were the case, then methodname.exists wouldn't work either. However, both methodname.exists and static constant booleans work correctly in static ifs inside modules individually for every struct that implements the module.

You had to use thistype. as a prefix to the constant in your module, right? I just tested it, and it didn't recognize the boolean unless I used thistype.

And it works!? It's like magic. I swear I tested this thing before with and without thistype. as a prefix and the module flatly ignored the boolean. Huh. Crazy things.

Thanks :D

Actually, Bribe, the example you showed is faulty.
static if thistype.ENABLE.exists then will always return false, unless you move the method ENABLE above the implement statement.