LÖVE

We're combining two separate issues.



Yours is that you prefer to use Class.__index = Class instead of a separate mtClass = {__index = Class}. (And then assigning a metatable to the instance with one of these.)

Both of these reuse the same table, so no extra ones are created at instantiation, which is good.
The thing with this, is that your version doesn't allow the Class table itself to have a separate __index lookup (pointing anywhere) from what the instance uses.

Yours: instance doesn't have a method -> instance index metamethod points to class -> look for method in class -> if not found, class metamethod points to class itself -> either recursion limit reached, or method not found.

Mine: instance doesn't have a method -> instance index metamethod points to class -> look for method in class -> class metamethod points to some other table, or to nothing -> either way, the method is either found, or it's not.

Not necessarily an issue, and it may be used rarely, but again, it's just a preference of mine to have my options open.



The other issue was the, imo, bigger one; namely that not having either of the above, and using local instance = setmetatable({}, {__index = whatever}) in the constructor always creates a separate {__index = whatever} table each time the constructor is called, so each instance will have a separate metatable, albeit with the same contents. It's plainly a waste of memory.

I think you're still making the same mistake in reasoning you were making earlier. Unless I'm missing something, this looks like more evidence that "Class.__index = Class" is confusing than anything else.

And if I am missing something, I'm definitely going to throw it in the "confusing" bucket.

Yep, i actually do; since no one ever set a metatable on Class itself, so __index is only used for the instances...
but yes, you are right; if nothing more, it's confusing as hell.

Then let me just correct myself by saying that IF someone wanted the Class itself to have a metatable, THEN s-ol's method will do the recursion tango. (IFF they would set the metatable to the Class itself, that is.)

I'm really sorry for hi-jacking this thread, but I have absolutely no frigging idea what are you talking about
The only thing I'm using right now is this.

Could someone PM me a couple of links to the places where I can read about metatables in-depth but sorta "for dummies"?

4aiman wrote: ↑Sun Feb 26, 2017 9:29 pmThe only thing I'm using right now is this.

That's basically what we were discussing. "The use of a table as an __index metamethod provides a cheap and simple way of implementing single inheritance" more or less sums it up. There are two common ways to do it; some prefer combining the fields of the "prototype" and the metatable into one table, and others prefer separate tables for each. The "combined table" approach can be seen here, and the "separate tables" approach appears in most of the other examples in lua-users wiki and PIL.

Oh
Thanks! I'll try to swallow (albeit I didn't understand the better half of your last post).
May I dusturb you via PM after I'm done with that link?

4aiman wrote: ↑Mon Feb 27, 2017 8:14 pm Oh
Thanks! I'll try to swallow (albeit I didn't understand the better half of your last post).
May I dusturb you via PM after I'm done with that link?

Of course! By "prototype" I meant the table that is assigned to __index (it's also named "prototype" in the PIL page you linked). By "metatable" I meant the table that eventually gets passed as the second argument to setmetatable.