Lua language

toneburst · 2022-03-15T14:21:45.145Z

ngwese:

That brings us to self.val = val, that line is assigning to the class prototype not the o instance. If you used o.val = val I would expect things to work.

Oh, it DOES!

Class = {}

function Class:new(o, val)
  o = o or {}
  setmetatable(o, self)
  self.__index = self
  o.val = val
  return o
end

function Class:changeVal(newval)
  self.val = newval
end

print("Create 'Obj1' instance with value of 10")
Obj1 = Class:new(nil, 10)

print("Create 'Obj2' instance with value of 12")
Obj2 = Class:new(nil, 12)

print("Obj1.val = " .. Obj1.val)
print("Obj2.val = " .. Obj2.val)

Obj1:changeVal(400)
print("Obj1.val = " .. Obj1.val)

print("Obj2.val = " .. Obj2.val)

Output:

Create 'Obj1' instance with value of 10
Create 'Obj2' instance with value of 12
Obj1.val = 10
Obj2.val = 12
Obj1.val = 400
Obj2.val = 12

The Name:function syntax is just sugar for passing whatever is referred to by Name as the first argument to the function. In the case of Class:new the self parameter is the table assigned to Class.

So

function Class:changeVal(newval)

is equivalent to

function Class.changeVal(self, newval)

?

Inside Class:new a new table is created called o which will serve as the container for instance specific values.

I think I kind of understand now. I should be able to get it working with that small modification, thank you!

It’s frustrating the tutorialpoint article doesn’t make this clear. I’d have thought that unique instance properties is a big part of the point of OOP…

ngwese · 2022-03-15T15:28:53.210Z

toneburst:

It’s frustrating the tutorialpoint article doesn’t make this clear. I’d have thought that unique instance properties is a big part of the point of OOP…

FWIW I quickly scanned the tutorialpoint page before responding and I think their tutorial is frankly incorrect. In each new function they define they start with o = o or {} but then they assign all of the would be instance values to the class table. I tend to stick with the official Lua docs at the end of the day despite their shortcomings.

The : vs . syntax is a source confusion in my experience. Hopefully the following sheds some additional light:

Class = {}

function Class:new(val)
  o = {}
  setmetatable(o, self)
  self.__index = self
  o.val = val
  return o
end

function Class:changeValA(newval)
  self.val = newval
end

function Class.changeValB(self, newval)
	self.val = newval
end

function Class.changeValC(nothing_special, newval)
	nothing_special.val = newval
end

Class.changeValD = function(self, newval)
	self.val = newval
end


local obj = Class:new(1)
print(obj.val)

obj:changeValA(2)
print(obj.val)

-- calling a function defined with implicit self parameter via normal function invocation 
obj.changeValA(obj, 3)
print(obj.val)

obj:changeValB(4)
print(obj.val)

obj:changeValC(5)
print(obj.val)

obj:changeValD(6)
print(obj.val)

Notice that I’ve defined essentially the same method using three different syntactic styles. Defining a function/method with Class:func is shorthand for assign the func key in the Class table to the following function and implicitly add a self parameter.

The second definition is much like the first but uses . so I add the self parameter explicitly to allow the use of the : “method call” syntactic sugar.

The third changeValC is like the second but illustrates that the name of the first parameter is not special.

The fourth form de-sugars it completely showing that defining “methods” is nothing more than assigning a name within a table to a function value.

toneburst · 2022-03-15T16:03:22.576Z

Thanks very much for the explanation, @ngwese!

I will pick a method, and stick to it , but great to have some background.

Incidentally, for my current project, I’ve gone for a mixture of Lua modules (where multiple instances with their own properties are not needed) and the above OOP approach where multiple independent entities with identical functionality seems to make more sense.

I’m largely a hobby coder (though I’ve been doing it a long time), so I do tend to get hung up on syntactical and structural concerns (often at the expense of getting the basic functionality to work, sadly, time being limited), so this is all interesting stuff.

Here’s a weird one (or maybe not, and it’s just a symptom of my lack of understanding):

Class = {}

function Class:new(o, val)
  o = o or {}
  setmetatable(o, self)
  self.__index = self

  self.reset = false

  o.val = val
  o.table = {}
  return o
end

function Class:changeVal(newval)
  self.val = newval
end

function Class:printVal()
  print(self.val)
end

function Class:setReset()
  self.reset = true
end

print("Create 'Obj1' instance with value of 10")
Obj1 = Class:new(nil, 10)

print("Create 'Obj2' instance with value of 12")
Obj2 = Class:new(nil, 12)

print("Obj1.val = " .. Obj1.val)
print("Obj2.val = " .. Obj2.val)

Obj1:changeVal(400)
Obj1:printVal()
Obj2:printVal()

Obj1:setReset()
print("Obj1 reset value: " .. tostring(Obj1.reset))
print("Obj2 reset value: " .. tostring(Obj2.reset))

produces the following output:

Create 'Obj1' instance with value of 10
Create 'Obj2' instance with value of 12
Obj1.val = 10
Obj2.val = 12
400
12
Obj1 reset value: true
Obj2 reset value: false

I’d have expected both instances to end up with the same values for ‘reset’, in this case, but that doesn’t seem to be the case.

juhbuba · 2022-03-15T20:03:49.777Z

toneburst:

I’d have expected both instances to end up with the same values for ‘reset’, in this case, but that doesn’t seem to be the case.

Unless I’m missing something, I don’t see a line where ‘setReset’ is called for Obj2.

Because Obj1 and Obj2 reference different data, Obj2 retains the values assigned when it’s instantiated (self.reset = false), consistent with your output.

toneburst · 2022-03-15T20:37:22.765Z

That’s the thing; I declared ‘reset’ on the class, not the instance table (as I did in my original code copied from the incorrect Tutorialpoint example).

When I did this before, changing the value of a property on one instance also changed it on the other. Not so, in this case, for some reason…

Anyway, my project is working fine now, so I’ll stick with the method I have

Thanks again.

ngwese · 2022-03-16T00:38:33.247Z

toneburst:

Obj1 = Class:new(nil, 10)
-- versus
Obj1:setReset()

The key to this mystry is paying close attention to what self is getting set to in each of these function invocations. Both Class:new and Class:setReset contain self.reset = ....

With Class:new(nil, 10) what is really happening is Class.new(Class, nil, 10), in other words self is pointing at the Class table so the reset value is being assigned in that table.

With Obj1:setReset() what is really happing is Obj1.setReset(Obj1) so in this case self is pointing at the Obj1 table. Lua doesn’t have any notion of a class variable vs instance variable. If the desire was to have reset act like a class variable then it has to be explicitly implemented as such:

function Class:setReset()
  Class.reset = true
end

In Lua setting values in tables is not influenced by the existence of __index. The table chaining behavior provided by __index only applies to getting values out of a table.

toneburst:

That’s the thing; I declared ‘reset’ on the class, not the instance table (as I did in my original code copied from the incorrect Tutorialpoint example).

Just to emphasize the above - Lua has no notion of instances and classes. As far as the Lua runtime is concerned the Class table no different from any other table. We are treating the Class table as a “prototype” for new instances (also tables) by defining values and functions in the Class table which we’d like to avoid having to redefine in each instance tables. The way we get Lua to find those shared values is by establishing a relationship between the instance table and the “class” table using __index.

toneburst · 2022-03-16T11:07:49.381Z

ngwese:

We are treating the Class table as a “prototype” for new instances

I’m vaguely familiar with the concept of “prototypes” from JavaScript.

Do you have an idea for a better name for Lua “pseudo-classes” and “objects”?

awwaiid · 2022-04-03T13:14:03.286Z

The two positions I rotate between is thinking of them as classes/objects (bags of state and methods that operate on that state, which mostly works fine if you squint) and thinking of them as tables.

The idea with embracing “tables” is that I say ok - this is a table with a bunch of key/values. Some are values, some are functions. The method “:” syntax is nice sugar to hand functions their current table. If an entry is missing it runs the stuff in metatable. Or in other words, I try to stop myself from making analogies and instead embrace the language as-is. YMMV

toneburst · 2022-04-03T14:07:04.577Z

I think “tables” is a bit too non-specific, though, given that tables are used for so many different things in Lua.

There has to be some name for the kind of table use that allows something very like classes and instantiation of objects with their own independent properties and methods.

I do tend to get hung up on these kind of terminology issues though. It’s a prevarication thing, I think

Incidentally, does anyone have any thoughts for or against using anonymous functions as clock callbacks, rather than calling a named function as in the docs?

==========================

Here’s another one: when writing modules, what are the relative benefits and drawbacks of using local variables declared at the top of the module file, over vars rolled into the module table?

local may_var = true

local Module = {}

-- Module functions etc.

return Module

vs.

local Module = {}

Module.myVar = true

-- Module functions etc.

return Module

I’ve been using a mixture of the two, but without any particular logic to my choice of one or the other, in any given case.

sixolet · 2023-01-13T17:42:40.748Z

I’m gonna necro this thread for something I’ve discovered to be quite useful in lua scripting that I want to share:

EDIT: I was wrong, as Trent pointed out below!

Here’s a stack overflow answer explaining:

stackoverflow.com

What are the correct semantics of a closure over a loop variable?

c#, javascript, lua, closures

asked by Panda Pajama on 04:02AM - 15 Jan 13 UTC

Original post

When you’re writing a loop in which you set a callback, like so:

for i=1,16 do
  things[i].action = function()
     do_things_with(i)
  end
end

It’s very tempting to do what I did above and reference the loop index in the callback, and hope that the callback “closes over” its value so that each thing’s callback has a different index it works upon. It does not work that way. The reason is that there is one single loop variable, and its value changes with every iteration of the loop.

Instead, do this:

for i=1,16 do
  (function(i)
    things[i].action = function()
      do_things_with(i)
    end
  end)(i)
end

The extra layer of function which you call immediately below with the loop index traps the loop index and lets the inner callback “close over” it, preserving the value within the callback.

Galapagoose · 2023-01-13T18:09:18.879Z

i’ve absolutely seen things like this in the past, but i just tested a simple example (lua 5.3.4) and it worked fine? perhaps there’s some finer point that makes it not work? the reason i was even testing was to suggest an alternative fix – you can just copy i into a local variable inside the for loop to allow closing over it.

anyway, my test case that seems to work fine:

t={ {}, {} }
for i=1,2 do
  t[i].action = function() print(i) end
end
t[1].action() --> 1
t[1].action() --> 1
t[2].action() --> 2

what i was going to suggest for your example is:

for i=1,16 do
  local i = i -- makes a copy of the loop variable which can be closed over
  things[i].action = function()
     do_things_with(i) -- uses the local copy of i
  end
end

but it seems in this simple example it actually isn’t necessary. i guess i’m writing to see if we can figure out the precise situation where this happens (because it absolutely does… sometimes).

sixolet · 2023-01-13T18:16:01.663Z

Wow you are right. I know I have been doing this for months because I had a hard-to-find bug in closing over loop indexes in norns param callbacks. I really do wonder where it comes up!

ampism · 2023-10-11T09:00:40.177Z

I have only ever added a script to my shield via maiden.
I now have a lua file that I want to put on there but don’t know how.
Could some kind soul please explain?

Update: sorted this now - thanks

xmacex · 2023-10-11T15:18:46.064Z

Create new file and copy+paste content is one way which isn’t away from Maiden, and there are a number of ways to connect to norns over SMB and SSH (scp) which work great. See the docs section transfer under WiFi / update / files.

ampism · 2023-10-11T15:21:53.820Z

Thanks- have sorted it now

XHG · 2024-02-26T06:26:25.817Z

I don’t know if this fits here but someone created a 542 byte Tetris in Lua, which I find pretty impressive.

The code is explained here:
https://www.gamelab.ch/?p=9218

andrew · 2024-09-06T22:53:05.834Z

lua is a perfect language with 0 flaws

local message = 'hello world',

print('my message:', message)
-- > my message: nil

robbie · 2024-09-07T09:22:20.167Z

andrew:

local message = 'hello world',

Ooof. That’s a frustrating one.

alanza · 2024-09-07T10:34:47.360Z

interesting that that’s the effect of the comma there

xmacex · 2024-09-07T10:44:59.856Z

That’s what I figured too, but trying it without the comma

Lua 5.3.6  Copyright (C) 1994-2020 Lua.org, PUC-Rio
> local message = 'hello world'
> print('my message:', message)
my message:     nil