I don't think that the OOP system is that strange. While Lua has all the tools to do OOP, you need some helper functionality to make it easy and clean, which is what their 'Object' global function does. I myself maintain a small object library that I always reuse in my projects, so it seems fair that this is similarly done for a framework.
Additionally, it'll help you stick to a compatible model that'll work with the framework itself.
I agree that the Windows-specific concept is a bit odd .. but then again maybe it can be one layer of a larger multi-os compatible framework in the future.
> help you stick to a compatible model that'll work with the framework itself
Fair enough.
> Windows-specific concept is a bit odd .. but then again maybe it can be one layer of a larger multi-os compatible framework in the future
It _could_ be, but I don't think it will be. It's not billed as ‘win32 interop tools you can use in your lua project’; it's billed as ‘complete framework that happens to depend on lua and win32’.
- The license will evolve to a full open source project once a certain degree of maturity will be reached.
- Yes PUC Lua because it's the reference. I won't go to the debate LuaJIT vs PUC Lua. Maybe a LuaJIT version could be released too in the future.
- Yes Lua has all the tools to do OOP, but it's not available out of the box for newcomers. That permits to inherit and extend the LuaRT provided Objects (File, Directory, Socket...)
- Yes Windows specific: Lua support on this platform is very poor and depends a lot on binary modules that must be compiled by hand, which can be a true nightmare on Windows for newcomers.
> PUC Lua because it's the reference. I won't go to the debate LuaJIT vs PUC Lua. Maybe a LuaJIT version could be released too in the future
Don't mean to debate, and I certainly wasn't criticizing the choice. I just thought it was unusual, since luajit makes interop with native code a much stronger focus than puc lua.
LuaRT main goal is to facilitate access to the Windows operating system functionalities without the need for C interoperability (no need for binary modules or FFI layers), hence the choice for PUC Lua :)
9 comments
[ 4.8 ms ] story [ 33.2 ms ] thread- CC-licensed code
- PUC lua instead of luajit, for a system focused on native interop
- Bizarre bolted-on OOP system (lua already has all the tools you need to do OOP!)
- Windows-specific (in this day and age?!)
Additionally, it'll help you stick to a compatible model that'll work with the framework itself.
I agree that the Windows-specific concept is a bit odd .. but then again maybe it can be one layer of a larger multi-os compatible framework in the future.
Fair enough.
> Windows-specific concept is a bit odd .. but then again maybe it can be one layer of a larger multi-os compatible framework in the future
It _could_ be, but I don't think it will be. It's not billed as ‘win32 interop tools you can use in your lua project’; it's billed as ‘complete framework that happens to depend on lua and win32’.
I think VSCode started as a Windows exclusive, and it turned out that tons of devs were still on Windows.
- The license will evolve to a full open source project once a certain degree of maturity will be reached.
- Yes PUC Lua because it's the reference. I won't go to the debate LuaJIT vs PUC Lua. Maybe a LuaJIT version could be released too in the future.
- Yes Lua has all the tools to do OOP, but it's not available out of the box for newcomers. That permits to inherit and extend the LuaRT provided Objects (File, Directory, Socket...)
- Yes Windows specific: Lua support on this platform is very poor and depends a lot on binary modules that must be compiled by hand, which can be a true nightmare on Windows for newcomers.
Regards,
Why?
Don't mean to debate, and I certainly wasn't criticizing the choice. I just thought it was unusual, since luajit makes interop with native code a much stronger focus than puc lua.