Using actual objects VS Module scripts to store data

Help and Feedback Scripting Support
#1

I’ve been using objects to store data like the folders in WithObjects in this example: ModuleVsObject

Now I’m wondering if it might be better to use module scripts like:

local CookieCompany = {}
CompanyName = nil
TotalCookiesCreated = nil
Factories = {}

CookieCompany.SetCompanyName = function(NewValue)
	CompanyName = NewValue
	print("New CompanyName:"..tostring(CompanyName))
end
CookieCompany.GetCompanyName = function()
	return CompanyName
end
CookieCompany.SetTotalCookiesCreated = function(NewValue)
	TotalCookiesCreated = NewValue
	print("New TotalCookiesCreated:"..tostring(TotalCookiesCreated))
end
CookieCompany.GetTotalCookiesCreated = function()
	return TotalCookiesCreated
end
return CookieCompany

to represent the data. The upsides to using module scripts should be slightly easier interactions with the data and maybe less ram usage? The downside being that you can’t look at the data in the explorer during the debugging process.

Does anyone have and advice or experience using module scripts like this and is it worth it or should I stick with using actual objects?

3 Likes
Is it possible to transfer animation track instances through scripts?
#2

ValueBase objects are no longer useful for games, and have not been for years. Modules should be preferred (they also offer the same benefits of getters and setters in class-based OOP, which ValueBase objects don’t). Personally, I’ve avoided ValueBase objects for years, and my code is for the better without them.

As for debugging, you can use the Lua debugger and print() calls to figure out what data is what.

RAM usage is a non-concern with either.

5 Likes
#3

To begin with, it’s much easier to just request a module than addressing every value object individually. It is also much easier to look at in the explorer since you have a single object which contains all the values, instead of hundreds of separate ones. But just as @Avigant said, there isn’t a major difference in RAM usage between the two.

2 Likes
#4

Meh. I’d like to disagree that “ValueObjects are useless”. If this intended to be from an objective stance, I disagree with it completely. I still use ValueObjects and sometimes combine them with ModuleScripts or use only one or the other. It’s up to your preference. One holds data in physical objects and another holds them in-script, nullifying the need to index the physical objects. Doesn’t matter, what ever is easier for you.

For the data structure you’re going with (which is relatively redundant), I think you’re going to want to take an ECS or OOP approach since your data structures are very… data-based. I personally would go with OOP to streamline the behaviour and structure of your companies. So to answer: both suggestions you posed are viable, but there’s a third one you can make.

ModuleScript CookieCompany:

-- Comments, variables, constants, other requires

local CookieCompany = {}
CookieCompany.__index = CookieCompany -- CookieCompany acts as both an MT and regular table

-- Internal functions

function CookieCompany.new()
    return setmetatable({}, CookieCompany) -- Attach CookieCompany to data table
end

-- Aliases?

-- Have this at the end, depending on your style:
return CookieCompany
return CookieCompany.new()

The reason people tell you that ValueObjects are useless is because they’re physical objects that exist in the DataModel. As for ModuleScripts, they allow you to hold data in-script while also allowing for manipulation; it’s like keeping everything in one nice and convenient place.

So to sum up: choose what your heart desires. There is no right or wrong answer. ModuleScripts may be more convenient for your use case, while ValueObjects are more comfortable and easy to work with.

The difference in how much RAM is used is extremely negligible and you shouldn’t note that as a concern at all. Do what you feel works best and gives you the most comfort. Experiment with new things. I personally prefer switching every now and then depending on how I feel, but for collaborative projects I typically use ModuleScripts due to their usage demands.

11 Likes