Object pooling class

Help and Feedback Code Review
4

This is definitely much better than the previous version.
One thing I would change is separating the allocation policy from the allocator itself.
I would avoid wrapping the whole thing inside closures or making it look like OOP. A pool is fundamentally just two pieces of state:

  • allocated objects
  • free slots

That’s very similar to how memory allocators work. They don’t shift the entire memory block every allocation - they simply track which slots are free.

For example:

local allocate = 32
local stack = table.create(allocate)
local free = table.create(allocate,true)


--fill
for i=1,allocate do
	local claim = next(free)
	free[claim]=nil--claimed
	stack[claim]=Instance.new("Part")
end
warn(stack,free)

--free
for unclaim=1,allocate do
	stack[unclaim]:Destroy()
	stack[unclaim]=nil
	free[unclaim]=true
end

warn(stack,free)

I would also avoid putting a max check inside the pool itself. That is application-specific policy, not allocation logic.

If one system wants a maximum of 32 objects and another wants 512, I’d rather have the caller decide whether to allocate or destroy instead of making every claim/free go through that branch.

This keeps the allocator self-contained and reusable.

Sometimes the simplest solution really is just a couple of tables and a few lines of code.

2 Likes