LÖVE

• I would put the properties-related code in a mixin, so that it can be easily reused by multiple classes without having to do "the metatable dance" on every class.
• I would still require getter and setter methods. That way, if someone (like me) doesn't want to use properties, they have the option to use the "old fashioned" methods
• Given the previous point, I would build the properties by convention: if there is a set_xxx method, then xxx is setable via obj.xxx = too. Similarly, if there is a get_xxx method, then xxx is gettable via obj.xxx. This way you would not even need the 'setters' or 'getters' variables.

-- properties.lua
local Properties = {}

function Properties:__index(k)
  return self['get_' .. k]
end

function Properties:__newIndex(k, v)
    local fn = self['set_' .. k]
    if fn then
      fn(self, v)
    else
      rawset(self, k, v)
    end
  end
end

return Properties

local class = require('middleclass')
local Properties = require('properties')

local Rect = class('Rect'):include(Properties)

function Rect:initialize(x, y, w, h)
  self.x = x
  self.y = y
  self.w = w
  self.h = h
end

function Rect:get_right()
  return self.x + self.w
end

function Rect:set_right(right)
  self.x = self.x + right - self.right
end

r = Rect:new(10,10, 100, 100)

print(r.right) -- 110
print(r:get_right()) -- 110
r.right = 200
print(r.right) -- 200
print(r.x) -- 100
r.name = 'peter'
print(r.name) -- peter

• return self['get_' .. k] was raising a stack overflow error so I'm now using self.class.__instanceDict["get_" .. k] instead;
• When a nil value was (not) found, an error was raised (by trying to call it as a function), so I've included a check.

-- properties.lua
local Properties = {}

function Properties:__index(k)
    local getter = self.class.__instanceDict["get_" .. k]
    if getter ~= nil then
        return getter(self)
    end
end

function Properties:__newindex(k, v)
    local setter = self["set_" .. k]
    if setter ~= nil then
        setter(self, v)
    else
        rawset(self, k, v)
    end
end

return Properties

Great news, considering I'm going to use those Rect's a lot!

I've done two changes on properties.lua to get it working here.

(And a minor tweak, comparing things specifically against nil gave it a big performance boost here

DanielPower wrote:Thank you again Kikito for your fantastic libraries. I use middleclass in all of my projects, and almost always end up using bump and inspect. I also wanted to mention that your blog taught be a lot about writing and using modules, and oop. I'll be upgrading to middleclass 4 when I get the time to start working on my game again. I'll report back with results compared to middleclass 3.

kikito wrote:

Great news, considering I'm going to use those Rect's a lot!

If you are planning to use it a lot, for intensive calculus etc, I would recommend you to measure how fast it is to not use middleclass at all too. Middleclass (and, in fact, any object-oriented library) is not a good fit for super-tight intensive calculations. For example, I would not use it for vectors or matrixes. For those, I think plain numbers + functions work best. There is no metatables - and there is no tables either. So your intensive code generates as little garbage as possible. That's what I did for the rectangles in bump.. Vrld has done something for vectors in vector-light.

I've done two changes on properties.lua to get it working here.

Ok!

(And a minor tweak, comparing things specifically against nil gave it a big performance boost here

That is ... unintuitive. As far as I know, if x is logically equivalent to if x ~= nil when x can't be false. And it seems that the first one should be faster since it is doing less. But that's efficiency for you; one never knows until the test is run.

DanielPower wrote:It turns out I've been using Middleclass 4.0 for a year