About self:calls() in the timer lib

[ghost]

I realize there was an issue about this a while ago, but I just keep scratching my head at this the more I work with it, and it's bit me in the ass more times than I'd prefer.

-- hump.camera:
local cam = Camera()
cam:moveto(1337, 1337) -- self call


-- hump.vector:
local vec = Vector(573, 573)
vec:normalize() -- self call


-- hump.class:
Person = Class{
  init = function(self, name) self.name = name end,
  speak = function(self) print('my name is', self.name) end,
}

local p = Person()
person:speak() -- self call (though completely necessary as per what the library does)


-- hump.timer:
local timer = Timer()
timer.update(dt) -- ...no self call.

I... can't say I understand why the timer is inconsistent with the usage of the rest of the libraries. Only now have I noticed that hump.signal seems the same way.

When something is required globally as a library, it is to receive no self as a standard. However, instances should be receiving self in their function calls because they're instances, no? They should be operating on a given self as per basic logic of OOP, not on an invisible floating self variable somewhere in space, right?

I'm guessing the main difference here is to create consistency between the usage of libraries and that of the one that instances them, but then you're creating inconsistencies not only with the other parts of the lib, but with common lua OOP paradigms themselves ...and in my brain. Code like this is ambiguous and misleading, when everything is created and documented as an instance, but it appears to be a global usage of hump.timer. Other than from the naming of the variable, one wouldn't be able to tell at first glance.

vector:dothing()
camera:dothing()
timer.dothing()

[vrld]

Yes, that is a weird and dangerously inconsistent API mishap that should be fixed.

[ghost]

Great, and apologies if my answer seemed overly wordy. Trying to work on that, heheh.