Are modules really neccessary?

[Ruke]

Hi pp, like the tittle says, are they really necessary?. I mean one can actually have the same functionality by using inheritance or even adding a delegate.

struct SomeModule
    public method sayHi takes nothing returns nothing
    endmethod
endstruct

struct Foo
    SomeModule module = SomeModule.create()

    public method sayHi takes nothing returns nothing
        call this.module.sayHi()
    endmethod
endstruct

I was implementing them in vrJASS but this question came...

If I don't implement them, the language will be smaller (actually better, runs faster, less things to do, less syntax to remember).

Isn't this an excuse not to implement them you lazy bastard?, well of course it is <.<.

 

[IcemanBo]

Isn't it good that you can initialisize with module if your library
can be used in some struct initialisizers of other libraries which would normaly run first?

 

[PurgeandFire]

@IcemanBo: He meant 'modules' as a concept, it is still used in vJASS for lack of better options.

I personally don't think modules are necessary. Usually if you need to 'copy' methods, then inheritance is sufficient.

Modules are mostly used for the initialization logic, as IcemanBo mentioned. Otherwise, the main uses I've seen for it has been as glorified textmacros. The advantage is that it allows multiple onInit(), plays nicely with structs, and doesn't conflict with struct variable names. But idk if that much "plug-and-play" utility is necessary. It would be better to just support extending a class and having support for abstract methods.

 

[Novynn]

I use modules for static methods that I want in multiple structs.

 

[Ruke]

@IcemanBo: He meant 'modules' as a concept, it is still used in vJASS for lack of better options.

I personally don't think modules are necessary. Usually if you need to 'copy' methods, then inheritance is sufficient.

Modules are mostly used for the initialization logic, as IcemanBo mentioned. Otherwise, the main uses I've seen for it has been as glorified textmacros. The advantage is that it allows multiple onInit(), plays nicely with structs, and doesn't conflict with struct variable names. But idk if that much "plug-and-play" utility is necessary. It would be better to just support extending a class and having support for abstract methods.

I was afraid of that... so far no modules on vrjass...

I use modules for static methods that I want in multiple structs.

Yep, but you can do this too without modules too.

 

[Bribe]

Modules are the only way to import private collections into a user's library, unless vrJASS runs the "keyword" type before textmacros. vJass does it the other way around.

What you could about initialization is say, any function which starts with "AutoInit" (for example) is caught by the compiler and made into an Init function.

 

[Ruke]

What you could about initialization is say, any function which starts with "AutoInit" (for example) is caught by the compiler and made into an Init function.

Simple & good solution, but I would like to make vrJASS similar to other languages so programmers can jump right into it and find it familiar (without having to learn anything else).

struct MyInitializationCode
    static method onInit
        // ...
    endmethod
endstruct

edit: Having to write that is like having to write the entire module initialization stuff (which is quite shitt*). I'm going to change so functions like 'main' or 'onInit' are treated as initializers. Thanks Bribe.

 

[Waffle]

/.../
What you could about initialization is say, any function which starts with "AutoInit" (for example) is caught by the compiler and made into an Init function.

We allready have that.. in jass.. and its an abomonation.
why do we need another way to spell InitTrig.

id rather prefer some way you could annotate a function that it should be an initializer(or annotate it in other ways, theres surely many other properties you might want to communicate to the compiler apart from please-have-this-called-from-main), or just stick with the current scheme (less work, less learning curve.., + compatibility with vjass is good for adoption even if some parts are not quite 100%)

also, i think that if vjass macros were not so toothless (ex:why the heck cant you nest them?! modules would not have happened. cjass macros pretty much take care of most of it, apart from the init, if only it was not so damn fragile..)

ex: you might want to annotate a function that it would become a no-op unless in debug mode.
ex: you might want some parameter to the function to actually be a compile time constatant(a function to get the compile time for instance so you would not need to update it manually..)
ex: code generation for different types..

definitely more work tho...