Instance:Destroy(timeout) and deprecate Debris service

Feature Requests Engine Features
#1

As a Roblox developer it is annoying to type out game:GetService("Debris"):AddItem(Instance,delay)
Instead, it would be much nicer to say instance:Destroy(delay) < not only would this save characters and is easier to comprehend but it also improves efficiency if you don’t cache Debris service (and still it would free up a precious local variable in that scenario)

In fact, I don’t even see a purpose for Debris service to exist at all, as that is the only (public?) functionality it has… so might as well just deprecate it while we’re at it xd

2 Likes
#2

Would there be a downside to write

delay(number, function()
    Instance:Destroy()
end)

?

#3

yes its slower and takes a lot more characters than both other options
its slower because:

  • you’re either indexing a global (delay) or local if it isn’t cached
  • you’re then calling a function which will call a function later which calls another function after that
  • you’re creating a new function
    vs
    Instance:Destroy(timeout): call a function on a local (namecall) with 1 parameter

but this isn’t totally accurate since Instance:Destroy(timeout) might have to call a function(s) etc depending on implementation although its fully in c
(delay calls the function you make from c too but the rest still applies)

1 Like
#4

Know the difference between premature optimization and legitimate performance concerns. Fractions of additional ms in performance difference and being too lazy to type out an additional function call don’t constitute the need for duplicate behavior to be tacked onto Destroy.

6 Likes
#5

Your issue is your use case is speed, which is a very poor one. You’re much more likely to get something like this considered if you used readability as your use case. Personally though, I don’t see this being added.

#6

I do know the difference between

The main issues here are clearly brevity and clarity :wink:
I can’t possibly understand why having a service dedicated to destroying an object with a timeout should exist.

@Kampfkarren again,

it seems like my posts aren’t brief/clear enough for you guys to understand :thinking:
maybe this is something important to be considered for api then?

@Fm_Trick asked for a difference between his code and what I’m proposing, I assumed brevity and clarity are implied so I went more in depth with performance

#7

It shouldn’t. Deprecating debris is fine – adding a timeout to Destroy, on the other hand, is not. There should only be delay → destroy.

No, this post is fully understandable – it’s just wrong. Roblox isn’t going to add a timeout to Destroy which duplicates delay(destroy()) just because you don’t feel like typing it out.

1 Like
#8

how do you know for sure?

thanks!

woah woah woah
at least speak for yourself and type out

delay(number, function()
    Instance:Destroy()
end)
#9
  1. It’s my job as a Lead Top Contributor to review feature requests
  2. As an intern, I had direct access to engineers, including explanations of how layers of duplicate behavior was a maintenance nightmare
  3. These same explanations have also been posted on the devforum, albeit in less detail. Example

There’s a difference between psuedocode and requesting future platform changes be blocked so engineers can test yet another edge case just because someone didn’t want to type an additional function call.

7 Likes
#10

Debris is good in the case that you can’t guarantee the script will exist the duration of the delay. For instance:

delay(5, function()
   object:Destroy()
end)
wait(1)
script:Destroy()

That will halt execution of that delayed function.

There are some use-cases where you might not be able to guarantee the script will exist long enough to perform the delayed function.

Debris is nice because it doesn’t suffer from this. You simply pass the object off to it and it handles the destroying for you.

Debris should not be deprecated.

Yes, I think a counter-point could be made that a well-architectured game would be designed in such a way that scripts responsible for deleting items wouldn’t themselves get deleted.

5 Likes
#11

Why would you ever call game.GetService and Debris.AddItem manually every time?

local Destroy do
    local Debris = game:GetService("Debris")
    function Destroy(Instance, Delay)
        Debris:AddItem(Instance, Delay)
    end
end
2 Likes
#12

Sorry I was not aware it was your job
I don’t understand how this would be adding duplicate behavior though: I’m saying to deprecate debris, so only one of them will remain

Also imo these “little” feature requests are what make an api nice to use

#13

When a script is destroyed all threads created from it are destroyed too (including ‘coroutine.create()’ ones?)? I would test this but not on computer rn

Also if that’s the case, it could be implemented just how debris is implemented (which is what I’m saying anyways) such that it is a special exception to the above

#14

I saved a meme-y part of my OP just for you

Anyways I wouldn’t do that because it’s also long… once I come up with all my annoyances with the roblox Instance api I will throw them all together into a script that augments datamodel and maybe even nil

#15

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