Identifing Interpreter

Mike

I have a script written for PUC Lua, which runs fine under LuaRT unmodified, as it doesn't use the io, os, or utf8 modules and all strings used are ascii. But some scripts that require my main script require the functionality of io and os. So in my main script, I create the global LuaRT = not not string match(arg[0], "luart.exe"). Then in the other script I use if LuaRT then sys = require("sys") end and then use if LuaRT ... for code throughout the script as needed. Thus the resultant script will run on PUC Lua or LuaRT equally.

By the way, my main script provides a more robust form of OOP than LuaRT's own, including super calls and an a missing method handler much like Ruby's, which among other things make delegation quite easy.

Samir

Hi Mike,

You can use the _VERSION global variable available in both PUC Lua and LuaRT, to differentiate the running interpreter.

You can also use the specific LuaRT interpreter (it lies in bin\std\luart.exe) that provide more PUC Lua compatibility :

It includes the "os" and "io" modules
Objects and instances have all a type of "table"

For the OOP part, you can use super calls in LuaRT easily that way :

function Derived:constructor(...)
   -- call constructor parent
    Parent.constructor(self, ...)
end

OOP in LuaRT is rather simple but effective for use as part of the framework. It's quite possible to improve it. What kind of functionnality are you expecting ? Can you tell us more about this "method handlers" ?

Mike

Samir
_VERSION would be easier and I has forgot that sys was auto included. For OOP I use a combination of proxy tables with metatables. This makes object attributes inaccessible to the user but it is possible to write methods to get and (for read/write properties) set an attribute. Indeed it's perfectly easy to define a write-only property, though I can't think of a use case. Missing method handlers work like this: x:doit(...) where x's class doesn't define doit, causes x:_missing("doit", ...) to be called if you have defined it, allowing custom error handlers. You could call _missing directly, but again off hand I can't think of a use case.

My main objective is code that runs in PUC Lua and LuaRT with little conditional code (some is unavoidable), mostly just for the fun of it. LuaRT's class system makes super calls less powerful than I have. Let's say I define Derived as a subclass of Parent, if I later need to change the class hierarchy so that Derived is a subclass of Middle and Middle is a subclass of Parent (say I need to change something in some subclasses of Parent but not others) Then I only need change the superclass in the class definition and super in Derived's methods will call the appropriate method, whether it comes from Parent or Middle. I've seen real world examples in production code. Java and Python accomplish this via a super keyword, I instead auto define a super method on each class that has a superclass.

Samir

Mike Missing method handlers work like this: x:doit(...) where x's class doesn't define doit, causes x:_missing("doit", ...) to be called if you have defined it, allowing custom error handlers.

It's clear I understand, but I think it may go against Lua philosophy to return nil for a field that do not exist.

Mike LuaRT's class system makes super calls less powerful than I have.

Yes you are absolutely right, I'm thinking to implement a super() global function to achieve this. Thank you again Mike for your feedback !

Mike

Oops underscores format text, how can I enter a literal underscore?

Samir

Mike Oops underscores format text, how can I enter a literal underscore?

Yes it's possible. You can escape markdown via the \ charcter before the charcter(s) that are being converted to Markdown 👍️

Mike

Samir
Re Lua philosopy, a return of nil would just result in x:doit(...) throwing an attempt to call nil, my __index metamethod throws an informative error, or if and only if your have defined _missing for x's class you can handle the error yourself.
By the way I use just two generic metatables, one for classes and one for objects.

I use method names beginning with a single _ to denote methods that are in some way special, such as _init, _add, _eq, ...