Should modules be controlled by loading them in a mod's main file or should this be processed automatically? On the one hand, ease of loading modules if it's handled manually, on the other it would take control out of the mod author's hands if they were to ever use this lib.
On the one hand, listing modules to be loaded via o:inc() is nice because it creates a separation from what's there and what's loaded. In other words, if a mod author has a module they're working on but doesn't wish to load into the user's game yet, they can let that just sit around in the modules folder until it's done, then load it through o:inc(). This is good for convenience sake as it doesn't mean moving modules out of the modules folder in order to work on them. This is how I felt about it when I was coding it, so that's what I went with.
The other aspect of this is that it means that WulfLib modules would need to have a way to not be loaded, rather than to specify loading themselves. After all, if a library is to be modular it defeats the purpose a bit if all modules are loaded in by default. So we'd still need to create an optional exceptions system instead to signify what modules wouldn't be loaded. Otherwise everyone would have to be very careful about what modules they include as they wouldn't want to include those they don't want to load. They might want to do that anyway? But I digress.
So, yes. I could just have all modules loaded in by parsing an lfs pull of WulfLib's and the mod's respective modules folders. (I keep wanting to call them directories as I'm old.) The upside, like I said, is never having to use o:inc(), just rely on everything being loaded in automagically. Still, the downside is requiring including a list of modules to not be loaded. I suppose I could also allow for the means of providing a list of modules to not be loaded for the mod too. At which point does that become the same thing though just with superfluous code to make it cleaner, quicker, and more effortless in some cases?
What makes this even more complicated is that there's version-checking in place for lib modules, so that if a big change happens to a lib-module, the version number can get incremented to signify that. If we're loading in modules automatically, what's the most graceful way to indicating what versions we should be looking for?
I've been going back and forth on this. It's an interesting thing to mull over.
Edited: I think that if I could think of an elegant, practical way of handling versioning with lfs-discoverable modules then I'd go with that, but I can't. I don't know if there really could be a way to do that in a functional way without the end result featuring so much bloat that it far exceeds the code necessary to implement the current solution. Thus, the current solution of o:inc() is inherently more elegant. Should I think of a way to handle versioning, my mind would change on that but... I don't believe that's possible.
Edited II: I've reached a happy middle-ground and I'm extremely pleased with the results. 1.4 incoming soonish!
Give Feedback
2 comments
Should modules be controlled by loading them in a mod's main file or should this be processed automatically? On the one hand, ease of loading modules if it's handled manually, on the other it would take control out of the mod author's hands if they were to ever use this lib.
On the one hand, listing modules to be loaded via o:inc() is nice because it creates a separation from what's there and what's loaded. In other words, if a mod author has a module they're working on but doesn't wish to load into the user's game yet, they can let that just sit around in the modules folder until it's done, then load it through o:inc(). This is good for convenience sake as it doesn't mean moving modules out of the modules folder in order to work on them. This is how I felt about it when I was coding it, so that's what I went with.
The other aspect of this is that it means that WulfLib modules would need to have a way to not be loaded, rather than to specify loading themselves. After all, if a library is to be modular it defeats the purpose a bit if all modules are loaded in by default. So we'd still need to create an optional exceptions system instead to signify what modules wouldn't be loaded. Otherwise everyone would have to be very careful about what modules they include as they wouldn't want to include those they don't want to load. They might want to do that anyway? But I digress.
So, yes. I could just have all modules loaded in by parsing an lfs pull of WulfLib's and the mod's respective modules folders. (I keep wanting to call them directories as I'm old.) The upside, like I said, is never having to use o:inc(), just rely on everything being loaded in automagically. Still, the downside is requiring including a list of modules to not be loaded. I suppose I could also allow for the means of providing a list of modules to not be loaded for the mod too. At which point does that become the same thing though just with superfluous code to make it cleaner, quicker, and more effortless in some cases?
What makes this even more complicated is that there's version-checking in place for lib modules, so that if a big change happens to a lib-module, the version number can get incremented to signify that. If we're loading in modules automatically, what's the most graceful way to indicating what versions we should be looking for?
I've been going back and forth on this. It's an interesting thing to mull over.
Edited: I think that if I could think of an elegant, practical way of handling versioning with lfs-discoverable modules then I'd go with that, but I can't. I don't know if there really could be a way to do that in a functional way without the end result featuring so much bloat that it far exceeds the code necessary to implement the current solution. Thus, the current solution of o:inc() is inherently more elegant. Should I think of a way to handle versioning, my mind would change on that but... I don't believe that's possible.
Edited II: I've reached a happy middle-ground and I'm extremely pleased with the results. 1.4 incoming soonish!