Using (Instance):Destroy() as we all know destroys an instance. However, there is an unknown way to destroy instances using game.Destroy. I'm not entirely sure how it is able to be called however. There is no documentation of it anywhere that I can find.
local d = game.Destroy
d(Instance.new("Part", workspace))
If anybody can provide an explanation of how Destroy is able to be called from the game that would be helpful.
Truth is, every instance has the ability to do this. In fact, anything that can be called as a method can be indexed as a regular variable, or property. Methods alone, are an abstract way of demonstrating that the function being called, is operating on that specific object (without passing it as an argument).
Tables (aka, Objects)
This ultimately brings us to tables
. All of these instances we refer to, are all fundamentally tables. Don't believe me? Try executing this code in studio:
print(getmetatable(Instance.new("Part")))
You should see a result that reads: "The metatable is locked" - Implying we're working with tables.
Anyway, the reason I'm bringing all this up is because we can simulate the exact same thing with tables (or objects), and their methods.
How methods really work
You've probably seen the correlation between using :
and .
to create (or call) functions in a table
before. Either way you write it, you can still call it the same way. So why are there two ways to write it in the first place? Well, it's all in the "self"
variable.
A somewhat hidden feature of methods (calling a function on a table (object), by using a colon), is the fact that the object you're calling the method on, is actually being passed as an argument to the function.
For example, say I had a table called "t", and a method attached to it called "GetSelf", here's what it'd look like:
local t = {} function t:GetSelf() return self -- yup, this is valid. this is by default defined as the table the method is attached to. end print(t:GetSelf()) -- calling it as a method (this will print a table value) print(t.GetSelf()) -- calling it as a regular function (this will print nil)
So, as we can see, calling it as a method (since that's what we assigned it to be) with the :
, gives it the ability to reference itself with a built-in variable
that we can't otherwise use if we call it using a .
That's the first part to understanding this. The second part, is realizing it's parameter is actually required if you're going to call it with a .
instead of :
Sounds confusing, but practice it enough, and you'll understand it faster than you think. Here's an example:
local t = {} function t:GetSelf() return self end print(t:GetSelf()) -- prints the table print(t.GetSelf()) -- prints nil -- BUT... print(t.GetSelf(t)) -- look! we're passing an argument to a function with no parameters, and it still returns the argument we gave it!
The reason the t.GetSelf(t)
example returned anything at all, is because we didn't call it as a method
. So by default, it's first argument is expected
to be the 'self' variable.
Applying this to your question
Applying all this information to your question, will work the exact same way! If we were to say something like:
workspace.Part:Destroy() -- that's calling the Destroy function, with the "Part" value set as the 'self' variable.
If we said something like this, however...
workspace.Part.Destroy() -- this won't work, because it has no argument! (no default 'self' variable, because we didn't call it as a method!)
So we could easily fix it like:
workspace.Part.Destroy(workspace.Part) -- and in this case, our argument could be anything! -- We could even say this! Instance.new("Part").Destroy(workspace.Part) -- it's all the same 'Destroy' function!
Anyway, hope this wasn't too confusing. If you have any questions just let me know, and I'll get back to it as soon as possible.