Scripting Helpers is winding down operations and is now read-only. More info→
Ad
Log in to vote
2

game.Destroy a thing?

Asked by 8 years ago

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.

1 answer

Log in to vote
11
Answered by 8 years ago
Edited 7 years ago

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.

0
Ok thanks, this really provided a deep explanation of my question. So in theory, you can call methods like .Clone from the game as well? wravager 35 — 8y
0
Yes, as long as they are implemented the same way, you can use a different instance's methods. BlueTaslem 18071 — 8y
Ad

Answer this question