Setting __index in different ways

[MMXtop]

I see that in OOP tutorials people use this:

module.__index = module
someTable = setmetatable({}, module)

But is it any different from using this?:

someTable = setmetatable({}, {__index = module})

If not, I would appreciate if someone would explain this in simple terms.

[2jammers]

Since index is a standalone metamethod, both will work fine. The only reason I believe it is attached to the table is for ease of access. As long as index points to a table or function they are both valid uses. The second metamethod can be used to hide the method from intellisense, though it can get less optimized if it isn’t a constant. Here, the metamethod would be created every time an object is created.

[V_ladzec]

@MMXtop

module.__index = module
someTable = setmetatable({}, module)

in this case you would be able to recursively access __index value of the module for example

module.__index = module
someTable = setmetatable({}, module)

print(someTable.__index.__index.__index.__index) -- you could do this forever

@MMXtop

someTable = setmetatable({}, {__index = module})

in this case you are not able to access __index value at all (unless you will use getmetatable function of course)

someTable = setmetatable({}, {__index = module})

print(someTable.__index) -- nil

both are valid it is just that you might not want that recursive access to __index value or even having __index in the hint list while coding just like @2jammers have said

[MMXtop]

I am relatively new to scipting so I have a few questions.

As I have found with a brief Google search, IntelliSense is like an autocomplete. But why would you want to hide it from it? Also, I am not sure what you mean by a “constant” and why and what exactly will get less optimized. Lastly, as I understand, in my second example, the “__index” metamethod is created every time, but does this have any effects compared with the first example where it is not created every time?

[MMXtop]

I know of recursion, when a function calls itself repeatedly, but not sure what “recursive access to __index value” means. Also, what is a “hint list” and what are the advantages/disadvantages of not being able to access “__index” value?

[V_ladzec]

@MMXtop

recursive access to __index value” means.

Since the value of __index is set to the table that it is being stored in every time you index __index the value of that entry would be the initial table

{
    __index = reference to itself
}

i think nested array would be a better name for this
As it is the same as below

{
    __index = {
        __index = {
            __index = and so on forever 
        }
    }
}

roblox does something when you type something like this to prevent you from running out of RAM although im not sure what exactly and where you could look that up

[V_ladzec]

@MMXtop

Also, what is a “hint list” and what are the advantages/disadvantages of not being able to access “__index” value?

hint list is a list that appears while you are coding to show what is accessable, what functions, variables are here by autocompleting your text

there are no advantages or disadvantages in having __index in the hint list it is just your preference whether you want it to display here or not
for example you are making some kind of module script

local HelperModule = {}

HelperModule.func1 = some function
HelperModule.func2 = some function 

HelperModule.__index = HelperModule

local MainModule = {}

function MainModule.new(arg1, arg2)
    return setmetatable({arg1, arg2}, HelperModule)
end

return MainModule

after requiring the module from another script

local Module = require(ModulePath)
local Object = Module.new(something, something2)

Object.

at this point a hint list so called intellisense should appear showing possible auto completions e.g properties, methods of that object

in this list you are going to see __index property if you are using the first method which you might not like as it doesnt add any functionality to the module and just hanging in there without a purpose

you might want to use the second method of setting metatables just to make your module look more clean in the hint list

[MMXtop]

So, the only difference in the two uses of __index is basically whether it will appear in the hint list or not?

[V_ladzec]

i personally use the second method as the first one is here only because roblox made it possible this way otherwise you would get stack overflow

but yeah

Handling self referencing tables

I have a deep copy function that copies a table as well as its metatable. The problem is when tables like this show up: MT.__index = MT When I run DeepCopy on MT, it searches all the stored values; it finds that the key __index stores the table MT, so it runs DeepCopy on that. But MT also has an __index which refers back to MT! This self-reference causes a stack overflow. A simple fix is to just not use this, and replace it with: MT.__index = function(self, Index) return MT[Index] end Howeve…

[MMXtop]

Alright, I’ll give you the solution unless someone else has to say anything.

[MMXtop]

Found a post that talks about how to solve the problem with unnecessary things popping up in the hint list. Just for anyone interested in this.

A new object-oriented programming idiom, and why you should ditch the old one!

There is a common idiom followed by developers when implementing the object-oriented paradigm in Luau, it looks as follows: local class = {} class.__index = class function class.new(x: number, y: number) local self = setmetatable({}, class) self.x = x self.y = y return self end function class:addXY() return self.x + self.y end return class This is a standard example of a class in Luau. For the purpose of the example, the class takes 2 numbers as arguments upon initializa…

[Ledlouis_10 (LED)]

The way you choose to set __index should depend on the nature of the value to which it is to be assigned.

@MMXtop

someTable = setmetatable({}, {__index = module})

In this way, the main issue is that you are going to create and assign a new metatable {__index = module} each time but all of these metatables will have the same content. Why create and assign 100 metatables with the same content when you can assign a unique metatable for all of them ?

For the sake of efficiency, we prefer to use the following approach :

@MMXtop

module.__index = module
someTable = setmetatable({}, module)

However, there are situations where it will be necessary to create a new metatable for each call. So, as I said at the beginning, the way you choose to set __index should depend on the nature of the value to which it is to be assigned.

[MMXtop]

By unique you mean one metatable for all of them? Also, in what way is it more efficient? Does it run faster, is it less laggy or something else? And if its not hard for you, could you provide an example where you would need to crete a new metatable for each call and an example where you would need to have only one metatable for all other tables, and why exactly you would use one method over another?

[Ledlouis_10 (LED)]

@MMXtop

By unique you mean one metatable for all of them?

Yes.

@MMXtop

in what way is it more efficient? Does it run faster, is it less laggy or something else?

It’s mainly the memory that will be most affected, creating so many identical metatables instead of using the same metatable will just overload memory.

@MMXtop

could you provide an example where you would need to crete a new metatable for each call

Having to create a metatable for each table is often needed when using private properties (properties that cannot be accessible through the table).

Here’s a ModuleScript containing code to create a table with a method movePart() which will be associated with a Part (the Part is the private property, it cannot be accessed via the table). Each time movePart() will be called, a Tween will be created and played to move the associated Part to its new position.

local TweenService = game:GetService("TweenService")
local Block = {}

function Block.new(part)
	local methods = {}
	
	function methods:movePart(target)
		local tween = TweenService:Create(part, TweenInfo.new(.2), {Position = target})
		tween:Play()
	end
	
	return setmetatable({}, {__index = methods})
end

return Block

As you can see, I create a metatable for each call because each metatable need it’s own methods since each one will have it’s own Part to move and it cannot be accessed through the table (it’s a private property).

Here’s an example of code using this ModuleScript.

local Block = require(script.Block)
local block = Block.new(workspace.Part)

while true do
	block:movePart(Vector3.new(4*math.random(1, 4), 2, 4*math.random(1, 4)))
	task.wait(.5)
end

@MMXtop

and an example where you would need to have only one metatable for all other tables

Actually, using one metatable for all other tables is more a way to avoid overloading memory than a need.

Let’s take the same ModuleScript that was used previously, except that this time the Part is no longer be a private property (it will be accessible through the part field in the table).

local TweenService = game:GetService("TweenService")
local Block = {}

function Block.new(part)
	local self = {}
	self.part = part
	
	local methods = {}
	
	function methods:movePart(target)
		local tween = TweenService:Create(self.part, TweenInfo.new(.2), {Position = target})
		tween:Play()
	end
	
	return setmetatable(self, {__index = methods})
end

return Block

Here’s what happens.

local Block = require(script.Block)

local blockA = Block.new(workspace.PartA)
local blockB = Block.new(workspace.PartB)

print(getmetatable(blockA) == getmetatable(blockB))
-- false because each block have it's own metatable

Each table still has its own metatable, and that’s a problem, because each call will add a new metatable to memory, and it’s possible to avoid this now that there’s no longer any private property. Here’s what the ModuleScript should look like instead.

local TweenService = game:GetService("TweenService")
local Block = {}
Block.__index = Block

function Block.new(part)
	local self = {}
	self.part = part
	
	return setmetatable(self, Block)
end

function Block:movePart(target)
	local tween = TweenService:Create(self.part, TweenInfo.new(.2), {Position = target})
	tween:Play()
end

return Block

@MMXtop

why exactly you would use one method over another?

As you can see from the examples, the method I choose will therefore generally depend on whether or not there are private properties.

[V_ladzec]

@Ledlouis_10

In this way, the main issue is that you are going to create and assign a new metatable {__index = module} each time but all of these metatables will have the same content. Why create and assign 100 metatables with the same content when you can assign a unique metatable for all of them ?

For the sake of efficiency, we prefer to use the following approach :

@MMXtop

module.__index = module
someTable = setmetatable({}, module)

yeah why to create a new table for each setmetatable call while all you need is to predefine that table and reference it in later uses
for example

local Metatable = {__index = module}

local Metatables = {}
for i = 0, 10 do
    Metatables[i] = setmetatable({}, Metatable)
end

which would be exactly the same as the first method as you dont create one more table {__index = module} each time

is one method more efficient over another? no they are the same

[MMXtop]

I am a bit confused. Is @Ledlouis_10 right when he says that one method is more efficient over another, or @V_ladzec is right when he says that they are equally efficient?

[Ledlouis_10 (LED)]

I think @V_ladzec was talking about these 2 methods when he said they were the same and not about the one that creates a new metatable with each call :

@MMXtop

module.__index = module
someTable = setmetatable({}, module)

@V_ladzec

local Metatable = {__index = module}

local Metatables = {}
for i = 0, 10 do
    Metatables[i] = setmetatable({}, Metatable)
end

Here’s a comparison of memory consumption for each of the 3 methods.

We can see that method 1 and method 3 are the same, as @V_ladzec said, while method 2 consumes almost twice as much memory (because a new metatable is created for each call).

Method 1 :

local module = {}
module.__index = module

local someTables = {}

while true do
	local someTable = setmetatable({}, module)
	someTable.value = math.huge
	table.insert(someTables, someTable)
	task.wait()
end

Method 2 :

local module = {}


local someTables = {}

while true do
	local someTable = setmetatable({}, {__index = module})
	someTable.value = math.huge
	table.insert(someTables, someTable)
	task.wait()
end

Method 3 :

local module = {}
local mt = {__index = module}

local someTables = {}

while true do
	local someTable = setmetatable({}, mt)
	someTable.value = math.huge
	table.insert(someTables, someTable)
	task.wait()
end

[MMXtop]

I understand it now. Thank you.