[UNSOLVED] Inheriting functions and making it accessable from the main module

Hi,

The title is exactly what I am trying to do. I am trying to inherit a function from function modules and make the function module accessable from the main module. For example, if I inherit functionToInherit to the main module, I should be able to do MainModule.functionToInherit.

Is this possible?

function functionToInherit()
	print("Inherited")
end

return functionToInherit
function Interaction.HandleFunctions()
	local Functions = script.Functions:GetChildren()
	
	for _, module in pairs(Functions) do
		if not module:IsA("Module") then
			continue
		end
		
		--TODO: Inherit the function inside of the module
        -- Make it accessable from this module
	end
end
1 Like

Are both scripts a ModuleScripts? I think that’s the best solution to do it in that way:

local module = {} 

function module.functionToInherit()
	print("Inherited")
end

return module

And:

local Interaction = {} 

local module = require() --put here reference to module to be inherited

function Interaction.HandleFunctions()
        module.functionToInherit() 
end

return Interaction

Now, both scripts should be ModuleScripts, but first one is only required but second one, which handles all the inherited modules (what you can do, prob it was done but I erased it for more clear code).

You can preserve the function names either by having just one function per ModuleScript like you show, and name the ModuleScript identical to the function, e.g.:

In a ModuleScript named “functionToInherit”

return function()
    print("functionToInherit printed this")
end

And in your Interaction class module you have:

function Interaction.HandleFunctions()
	for _, module in pairs(script.Functions:GetChildren()) do
		if not module:IsA("ModuleScript") then
			continue
		end
		
		Interaction[module.Name] = require(module)
	end
end

After the Interaction.HandleFunctions() is called once, Interaction.functionToInherit() can be used, but this trick limits you to one function per ModuleScript which is a waste of Instance memory.

It would be nicer to not use the ModuleScript name for anything, and instead have the function modules return tables with 1 or more named functions, like so:

In a ModuleScript named whatever you want:

return {
    functionToInherit = function() print("functionToInherit printed this") end,
    add2Numbers = function(a,b) return a+b end,
}

Then in your main module:

function Interaction.AddFunctions()
	for _, module in pairs(script.Functions:GetChildren()) do
		if not module:IsA("ModuleScript") then
			continue
		end

		local newFunctions = require(module)
		for functionName, func in pairs(newFunctions) do
		    Interaction[functionName] = func
		end
	end
end

There are ways to do this a bit more elegantly, but these fit your existing structure. You should of course also add checks to make sure modules are not trying to add different functions with the same name.

P.S. in your example you have IsA("Module") which will not work. I have changed this to IsA("ModuleScript") in my copies of your example.

1 Like

Why not just have all the functions in that module or require them as needed? Seems like extra work unless you’re doing actual OOP inheritance. Another solution is to have a separate utility module that has the functions.

I did not mean to reply to that…

To make my code my readable instead of having thousands multiple of functions inside one module. These functions take a lot of lines and it doesn’t look good.
Screen Shot 2024-04-03 at 8.34.32 PM

It also makes it efficient to add new public functions.

@EmilyBendsSpace gave you the solution though

You can take modularity too far though. I figured you were wanting to compile a bunch of helper functions into a library module like this, but even so, if you have just one short function per ModuleScript, you lose a lot of effciency in some areas like publish time, size of your .rbxl on disk, and time required to replicated all the ModuleScripts from server to client (if they’re in ReplicatedStorage or anywhere else that automatically replicates to clients).

There’s a middle ground, where you can still have your helper functions organized into submodules, but not have to strictly keep one function per module. Eventually you’ll come across a case where you have a number of related functions that make organizational sense to keep in the same module. That’s why I wanted to show you the example of that as well.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.