Cross-mod require() limitations?

[eradicator]

(This is not strictly a request. But as it is highly technical i feel it is unfit for the suggestions forum.)

So now that 0.17 is going to have the ability to require() other mods files i have thought about that a bit. And while i can see great potential for building libraries and a community of code sharing, i can also see great potential for bugs. If i write a module for my own mods without explicitly considering the possibility of another mod requiring it then, especially in the data phase, this is going to lead to serious name conflicts for global variables, which will likely break both mods involved. In the control stage every event handler would be run twice, etcpp. There's also the legal side where it might be against the license of a mod to be require()'ed by another. And i'd honestly prefer not having to rely on other mod authors to do "the right thing" to keep my own mods bug-free.

So i was wondering if anyone thought about putting some sort of limitation on that? Maybe a per module opt-in value? Or some entry in info.json? Or a new top-level file required.lua which is the only file that can be cross-required so i can precisely decide what to export and what not?

[Rseding91]

This has a simple "not your problem" answer. Write your code how you see fit and if someone else takes it and does something dumb with it you just don't care.

There's nothing that stops someone from copying your files into their mod now and causing issues.

Anything we might come up with to try to prevent people from doing stupid things just leads to the same end result: someone invents a dumber way to break it.

[eradicator]

Anything we might come up with to try to prevent people from doing stupid things just leads to the same end result: someone invents a dumber way to break it.

Haha. :D. Well, if there was an info.json flag to completely block a mods files from being required they'd have to at least break it using the old way (copying files) ^^. Seeing that you often argue about "how easy is it to break" (i.e. access to data.raw built-in vs having to hack order strings) i do think that could at least preserve the current difficulty.

Thanks for the answer though :).