Why do some OSS Modules return a frozen table

I don’t really know how else to phrase the question so yeah, I have currently assumed that it’s somehow more efficient but I’m very curious about the why and how portion or even if I should start doing this with some of the modules I create myself.

Examples would be Suphis data store module and LuminFramework/CanaryEngine

Freezing the table prevents the user of the module from making breaking changes in the table. However, I don’t think many people would modify the table anyway so I don’t know if table.freeze really is worth it in that situation. I haven’t used it.

Freezing the table doesn’t necessarily entirely prevent breaking changes anyway because the table might contain references to mutable objects whose state is supposed to only be mutated by internal code, not user’s code.


There’s 2 big reasons why immutability is so favored upon:

  • It’s really easy to listen for changes

If you have a property/table that changes only when you call a method to it, that method body can also fire changed events.

This is way cleaner and more performant than constantly checking.

  • It’s predictable

A large class of bugs arise from values and properties changing from underneath you (this is why Vector2s and the like are immutable by default).

Immutable values circumvent all that - the only tradeoff is that you’ll have to be explicit when trying to change them (eg: v2 = Vector2.new(0, 1, 0) instead of v2.y = 1).

1 Like

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