OOP suggestions

Mike

I note with approval the plans to include a super() function.

This morning I tinkered with adding Ruby style mixins. Translating to LuaRT's native syntax,
I did the equivalent of extending Object to take multiple parameters such as Derived = Object(Parent, ...) where the varargs represent zero or more classes to be mixed in. Derived does not become a subclass of the mixins but rather their methods are copied into the list of methods for Derived (taking the mixin classes in order) and they will behave exactly as if Derived had defined them. Say you have several types of unrelated classes where you wish to do logging. You could define a mixin Logging = Object {} and define one or several logging methods on Logging and have them brought into as many classes as need them: A =Object(ParentX, Logging) B = Object(ParentY, Logging) C=Object(ParentZ, Logging). Notice Logging does not need a constructor or destructor as Logging objects are not constructed in the usual sense and become an indistinguishable part of the objects they are mixed into. In general, mixin methods do not define properties but assume the class it mixed into provides them as for example assuming that a name property is defined on Derived (or inherited from Parent).

Mixins give 90% of the advantage of true multiple inheritance as in C++ or Python with less than 10% of the complications.

You might consider a similar system for LuaRT at some point.

Samir

This is a great idea 👏👏
Mixins are very suitable to LuaRT OOP, and I agree with you with the balance advantages / complications.

I have it implemented just now : mixins are tables, and supports property getters/setters
Implementation was just easy to integrate with LuaRT codebase (a few lines of code).

It will be available in next LuaRT release 🙃

Samir

Update :

super() brought more complexity as I needed to implement ancestor traceback before Object instance method calls... but it's done !! 😮‍💨

Mike

Extremely good to hear. I was certain you'd find mixins quite worthwhile if indeed you hadn't already thought of it yourself. I'm looking forward to the next release, and to studying the LuaRT source when you make it available. I've always found mixins far easier than multiple inheritance, and more useful than Java style interfaces, which have method signatures but no implementation.

Mike

There are two ways of calling super:

fuction X:dothis(...) return super(...) --calls the suparclass version of doit, as in Java end

function X:dothis(...) return super():dothis(...) --as in Python end

Which way did you implement super (either is perfectly acceptable)?

Samir

Mike Which way did you implement super (either is perfectly acceptable)?

We are limited by the Lua type system, and the way Lua manage self and the ":" method call convention.
For now, super() can be used that way :

-- parent method call
super(self).constructor(self,...)

-- parent property get/set
count = super(self).openfiles
super(self).year = 2022

Mike The ability to define read only properties for my own classes

LuaRT can already implement readonly properties, with a setter method :

function Square:set_readonlyfield()
    error("Square.readonlyfield is a readonly property")
end

Mike The ability to define iterators for my own classes. Not essential but highly desirable.

For the moment, it's possible from the C side (yes, it will be possible to write LuaRT binary modules to define custom objects as for sys.File and so on...) and it is planned to do it from Lua too.

Mike

Things I'd like:

The ability to define read only properties for my own classes. This is essential. If LuaRT already has this capability it needs an example in the tutorials.
The ability to define iterators for my own classes. Not essential but highly desirable.

Mike

The super() implementation is rather Python-esque, very usable and has advantages over Java style. You don't often need

`function X:dothis(...)
return super(self).dothat(self, ...)
end'

but I have seen use cases.

I will try out read only properties.

Mike

I just tried out read only properties and they work properly if and only if the initial value is set in the parameter of the object call., an attempt to set it the constructor errors, problematic if the initial value is a result of a complicated calculation -- your class is forced to rely on an outside function,; possible, but will seem like a wart on the language.

Suggestion:

In a constructor only, self.name = x won't call self:st_name(x) but if needed you can call self;set_name(x) explicitly (when the property is read write). You would need to track if self is being indexed in it's own constructor.

Destructors may need similar functionality for cases where a property is an object or other table and it is desired to set the property to nil. The are cases where this facilitates efficient garbage collection.

Samir

Mike
It was just an example.
You just can use an empty setter method. This will prevent any property affectation without error.

The problem you describe concerns in fact private fields. True privacy in Lua is based on scoping.
LuaRT OOP used the same mechanism to achieve field privacy :

User = Object {}

function User:constructor(uid, name)
	self.name = name
       
        -- getter method using the local value of uid (not accessible out of this scope)
	function self:get_uid()
		return uid
	end
end

-- Empty uid setter method to make User.uid readonly
function User:set_uid()
end

-- Create a new user
sam = User(408, "Sam")

-- Prints "Sam"
print(sam.name)

-- Prints "408"
print(sam.uid)

-- Prints "nil"
print(User.uid)

-- no effect, "uid" is a readonly property
sam.uid = 512

-- Prints "408"
print(sam.uid)

A more precise documentation on OOP will be available with the new website.

Mike

The above code works perfectly and a short note in the documentation on defining read only properties will cover the topic well. There is however a loophole: rawset(sam, "uuid" , 617) does change the uid property. Assuming LuaRT's internals can distinguish between tables used as object and plain tables (as you must be doing judging by how type works), the version of rawset exposed to users should not work on objects, only plain tables (probably rawget as well, otherwise rawget could bypass a getter that does something to the return value before returning it--I've seen real world use cases).

Samir

Mike rawset(sam, "uuid" , 617) does change the uid property

A simple way is to restrict rawset() to tables not objects. Have to work on it.

Mike

With the change in rawset, read only properties will work perfectly. The corresponding change is rawget is far less essential, though it has some uses, such a forcing the user to use the getter to retrieve certain properties so to for example requiring the insertion a time stamp into a returned table or object. The latter could be done by validation code in the function that uses the return value which checks for a timestamp, rejecting data that doesn't have one.

Samir

I have updated rawset() and rawget() to be used only with tables, not with objects.

Seems like LuaRT 1.0 will be a "special OOP" release 🤔 !

Mike

I appreciate your efforts. In my opinion, if your do OOP at all, you should do it well, and you are definitely doing that.

Mike

Looking forward to defining my own iterable classes on the Lua side.

Samir

Mike Looking forward to defining my own iterable classes on the Lua side.

I'm thinking of how to achieve this in a simple and "natural" way with Lua

Samir

Update :
✅ Object iterator is implemented and will be available in next LuaRT release.

To keep it simple, an Object will be iterable if it defines an "iterator()" method.