Intellisense WaitForChild typing


#1

Right now Intellisense can infer the type of a GetService call. For example, if I type game:GetService("RunService"): then the methods of RunService will show up for me. It would be incredibly useful if WaitForChild could do the same thing. Intellisense would take the first parameter of WaitForChild and see if there is a child with that name. If there is then it would respond to . and : just as it would if the child were directly accessed with a .. If there is no child with that name then it should do what it does now (nothing).

Basically, aaa.bbb and aaa:WaitForChild("bbb") should effect the same response from Intellisense if bbb is a child of aaa.


#2

This would be qute handy.


#3

Don’t forget FindFirstChild on this too. I think the largest issue why this doesn’t exist right now is that they have no way of knowing what the kind of object you are waiting for/finding is.


#4

I believe FindFirstChildOfClass is still a thing, and hardly known about.
http://wiki.roblox.com/index.php?title=API:Class/Instance/FindFirstChildOfClass


#5

WaitForChild makes sense because you might want to use it for client-side stuff to wait for things to replicate; thus, there are cases where the object exists in the game hierarchy (which is why intellisense makes sense for it), but there still might be value to have the client wait for it.

However, intellisense withFindFirstChild doesn’t make a lot of sense. If the object is there, why are you using FindFirstChild to begin with?


#6

Because it may not always be there, and it’s safer to use that and double check than just blatantly reference it and hope it works every single time.


#7

Yes, I’ve done something like:

local rightShoulder = torso:FindFirstChild("Right Shoulder")
if not rightShoulder then return end
doStuffWithRightShoulder()

but this is on an object that is created at runtime. Even when working with something other than character joints the objects are created at runtime. Because of this, they wouldn’t exist for intellisense to pick up. That being said, do you have any specific use cases for when something is already created in Edit mode that may not exist while the game is running?


#8

My game is over 100,000 lines of code and doesn’t use WaitForChild once. Ideally your entire script should run after what it depends on replicates. I avoid yielding as much as I can.


#9

How do you ensure that a script runs after what it depends on replicates? Also there’s nothing wrong with yielding to wait for all dependencies at the beginning of a script. I think that’s very common practice.


#10

My game has 1 LocalScript and 1 Script that require ModuleScripts when they’re needed


#11

If this were the case, WaitForChild would never have been created. Maybe for your specific design preferences it’s yucky, but this is the first time I’ve ever heard anything negative about WaitForChild. You’re right that there’s no need to yield on the server because AFAIK scripts run after the game is loaded, but objects aren’t replicated to the client instantly. Not a problem if you’re creating them from the client or passing data over RemoteEvents, but disjunctive services (e.g. StarterGui and Characters) aren’t able to cooperate in that way.


#12

What mainly bothers me is seeing people exclusively use nested WaitForChild’s many times in a script because they can’t reliably predict what gets replicated when. WaitForChild can be used for rapid prototyping and compatibility with other scripts, but a good game architecture has clearly defined dependencies. I stopped using StarterGui long ago because gui scripts ran before the gui finished replicating (I’m not sure if this is still the case) which is just broken. I think a character’s model should be fully populated with roblox’s default instances before it is set as player.Character, and gui’s should be fully replicated before the gui scripts start running.

Instead of waiting for things to snap into place over time, I prefer when scripts request/create them proactively; ModuleScripts enable us to do just that. Imagine if you needed to use :WaitForService() instead of :GetService(), that sums up how I feel about :WaitForChild().


#13

This looks like clearly defined dependencies. It waits once at the beginning of the script for everything it needs to replicate.


#14

You don’t need to defend yourself. This thread shouldn’t turn into a discussion of who’s development practices are better, and it’s not widely argued that WaitForChild is bad, so a feature request for it is reasonable.


#15

I recently found out that Intellisense infers the return type of modules. However, it can’t when the path to the module has WaitForChild in it since it can’t infer the type of the ModuleScript itself. I’m going to bump this since it would make coding in Studio so much better.


Is there any way to get intelligent object oriented autocompletion in scripts?
#16

The problem with WaitForChild is that every time you use it, you are potentially setting up an infinite yield.

I think Tomarty has it right on this one. It’s a trap.