这是indexloc提供的服务,不要输入任何密码
Skip to content

Conversation

@ARGAMX
Copy link
Member

@ARGAMX ARGAMX commented Nov 20, 2025

Describe what the proposed change does

We have a lot of calls in our code like object.humanoid_class == "Handyman"

I found 69 matches in 25 files (!).
(Do you also smell a lot of git conflicts?) 😁

Some objects directly read the fields of another object and also externally compare this field value.

It was a bit bothering me as I think it's a typical violation of encapsulation for me.

Logically, this should be a call to a method of this object, to which the object for comparison is passed.
And the object itself decides the results of this comparison.

Filed humanoid_class should not be exposed outside and should not participate in external operations.

So I propose to rework this to call the appropriate method.

object.humanoid_class == "Handyman"
->
object:isType("Handyman")


Overall, it a minor issue.

I was more concerned that this strange approach was being copied and pasted everywhere and was growing. So reading and externally comparing the humanoid_class field seemed like a common practice.

I was working on another task, and it required me to copy this comparison to other places one more.
But I realised I didn't want to copy that and decided to tidy things up a bit.

Oh yeah, and on top of that, it'll possible break something somewhere. How could it be otherwise? 😂

But I went and lit a candle in the church to prevent this from happening. 🤞🏻 🕯️

…ss == "className"> replaced to <humanoid:isType("className")>
@ARGAMX ARGAMX added the PR:Refactor PR deals with mostly reorganising code to make it better. label Nov 20, 2025
@github-project-automation github-project-automation bot moved this to In Progress in 0.70.0 Release Nov 20, 2025
Comment on lines +818 to +821
function Humanoid:isType(humanoid_class)
return self.humanoid_class == humanoid_class
end

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need this; as we already have code made to support a check in a better way: class.is(humanoid, ClassName)

function class.is(instance, class)
local typ = type(instance)
if typ ~= "table" and typ ~= "userdata" then
return false
end
local methods = instance
while methods do
if methods == class then
return true
end
local mt = getmetatable(methods)
methods = mt and mt.__index
end
return false
end

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or you could make this function call class.is instead too.

@Alberth289346
Copy link
Contributor

I was more concerned that this strange approach was being copied and pasted everywhere and was growing. So reading and externally comparing the humanoid_class field seemed like a common practice.

Lots of newbie programmers hacked the code. They tend to copy/paste already existing code blocks.
Not that you can blame them. The Lua programming model of global read and write access is essentially broken for our scale of code.

@Alberth289346
Copy link
Contributor

Alberth289346 commented Nov 20, 2025

Of course, much of the code after class checks should probably be moved the proper derived class.
The Humanoid base class is generic both as base class and as collection of code pieces that affect one or more specific derived classes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

PR:Refactor PR deals with mostly reorganising code to make it better.

Projects

Status: In Progress

Development

Successfully merging this pull request may close these issues.

3 participants