naming convention

[SwissalpS]

Question A

Currently I have named the libraries with very short names:

• log
• log_env
• string
• string_env
• table
• table_env
• vector
• vector_env
• vector_basic
• vector_basic_env

This soon raises a namespace issue when another mod also provides libraries with the same names. It wil be a race condition which one gets set in the mooncontroller.luacontroller_libraries table.

So once the name of this mod is decided, we might be able to add namespace:

• modname_or_shorthand:string
• modname_or_shorthand:string_env

For now I could easily live with: SwissalpS:string but that isn't a very bright idea considering the option to maintain in mt-mods or similar in the future.

Related Question B

For now require('string') will just return a table with the string functions, leaving it to the user if he wants to assign it to a global or local variable. (or only parts of it to global space). While require('string_env') returns the same table but also adds the functions to env.string.

Does this naming make sense or should the default be adding to env? So string_env would be just string and what currently is string would be something like string_raw.

If so, what would a good name instead of raw be?

All suggestions and ideas apreciated, thanks.

[S-S-X]

I think _raw stuff probably shouldn't be there at all. And that basically also makes _env stuff completely unnecessary. Having all that probably just complicates things without any real reason to do so, I'm pretty sure it would be a lot better to define single backwards compatible API for extensions.

To give access to raw just do not load extensions and to apply extensions to string just require("string_extensions")

For possible race conditions I don't think there's need to solve it here and it would be better to do this with we're all adults here mindset instead, I mean maybe guidelines but no restrictions.

Only good libraries will be installed anyway, I think that's well enough to limit what would be added and what wont be added.

There might be some issues with this, mainly if "self-regulation" (of extensions) fails for any reason but for most stuff, even small things, it seems to work very well.

[SwissalpS]

Thanks for your input.

To give access to raw just do not load extensions and to apply extensions to string just require("string_extension")

I don't quite understand what you mean here. Without require('extension') luaC has no access to any of extension functions.

I mean maybe guidelines but no restrictions.

Yes, guidlines in mooncontroller docs would be great, so we don't totally work in different ways. Users apreciate consistency.

[Klaranth]

So, let see if I get this .... Raw is basically version zero? And which other conventions on naming are there?

[SwissalpS]

Raw is basically version zero?

no, raw is just a bad name for saying that when you local v = require('vector_raw'), v will contain a table with the vector functions whereas if you do local v2 = require('vector_env'), v will have the same contents as v but the env will also contain it -> there is a global calledvector``.

• with _env variant you can just call vector.add(p1, p2) from anywhere in code.
• with _raw variant you can use the functions only in the scope where you loaded the library v.add(p1, p2)

A user may want _raw variant because he has already got a global called 'vector' or his code only sometimes needs vector functions and the other times he wants to keep global space slim.

[Klaranth]

Out of curiosity, did you ask ChatGPT for input? :)

[SwissalpS]

nope, I like human input :D