Should ALL LL additions to Lua, be mvoed into a namespace?
closed
WolfGang Senizen
Right now lua in sl declares quite a lot of things in the "global namespace".
This.. may cause issues down the line.
As I understand part of the push for lua is problems with updating mono... i can see 5 years into the future, luau updates to v0.744 and adds uuid or some other conflicting name, and now updating luau is a problem...
Log In
Signal Linden
closed
We're unlikely to do namespacing for most things if it'd make scripts more annoying to type out. Particularly something like
PRIM_COLOR
vs llconst.PRIM_COLOR
.A quaternion will probably never be added to Luau as they've used
vector
s for them for years now, and if they did it'd likely be in the Roblox script library, not in Luau proper. Pretty much the only reason there's a native vector
type in Luau is because 3 floats fit perfectly in a TValue
struct and therefore needs to be implemented in the VM itself, whereas a quaternion won't and doesn't.Regarding concerns about upgrading, we merge in upstream changes every so often, and it takes about an hour. I wouldn't worry about SLua lagging behind Luau as much as SL's implementation of Mono has lagged, that was a big factor in us choosing Luau as a base codebase, it's much easier to reason about, and even upstream changes that completely change internal VM semantics are painless due to Luau's excellent test suite.
Regarding event handlers living in the global namespace, that's a valid concern. Event handlers being globals is a bit of a hack, and we're working on something better.
There is one kind of namespacing that we are interested in, and that's builtin function versioning. The
llXorBase64StringsCorrectReallyWorksThisTime()
situation is pretty unfortunate, and we're still working out how we want to handle that, but we're still working out how it should be handled. Likely scripts will save the library version at the time of saving by default, and there may be some mechanism to request a specific library version. This will come after the alpha phase.Thornotter Resident
For example, a quaternion type is reasonably likely to be added to Luau in the future given it already has a vector type.
Kadah Coba
+1 for a namespace.
Very Vanilla
Future-proofing in this way is probably a really good idea. Hindsight is 20/20 and all.
I also think it helps all of the pseudo-event functions stand out as separate and important from built-in or user-made functions, as there's no user-friendly distinction between say, touch_start() to any other function currently, even though touch_start() is automatically called from outside.