Improve the type-strength of Instances in the reflection system

Feature Requests Engine Features
,
#1

As a Roblox Developer, I was always a little confused as to why certain functions and events say their argument type is Instance when in reality it might be constrained to a specific class type.

Examples

Function arguments that take instances

Function void VehicleSeat:Sit(Instance humanoid)

  • Does this function allow any instance, or does it only allow a humanoid? The name of the argument might suggest so, but it isn’t explicitly stated.

Function void VehicleSeat:Sit(Humanoid humanoid)

  • I think it would be much nicer if it could be defined like this.

Events that pass Instances

Event UserInputService.DeviceGravityChanged(Instance gravity)

  • Without knowledge as to how this event works, it isn’t immediately obvious what gravity is represented by.
    • Is there a Gravity Instance?
    • How do I know what kind of object it is without testing it in a runtime context?

Event UserInputService.DeviceGravityChanged(InputObject gravity)

  • With the instance explicitly defined, you can see that it’s an InputObject that is measuring the gravity of the device.

Use Cases

Right now, the primary goal of this change would be to provide some sort of compile-time context to Roblox’s reflection system as to what specific kind of class is accepted in an Instance function argument.

This information could then be extended to the JSON API Dump feature (which is a part of Roblox Studio retrieved via RobloxStudioBeta.exe -API [filepath]. This file is used by developer.roblox.com for automating the API documentation pages.

As long as the general structure of the format remained the same, I don’t anticipate there would be any problems integrating such data into the system. I designed it to reserve space for a ClassName to be explicitly defined in the place of just “Instance” in the hope that, at some point it may be possible to provide that information.

Possible Solution?

I came to realize this was a limitation of Roblox’s reflection system under the hood when I worked on the JSON API Dump feature during my internship last summer.

Without delving too much into the internal details, the best I can suggest is some sort of wrapper class that facilitates strongly-typed constraints to an Instance argument, which could have its constraints accessible to the JSON API Dump upon request.

This seems like the most feasible solution, as it wouldn’t require any large scale refactoring. I’ll leave it at that for now.

Conclusion

Although this use case might seem a bit niche, this information was lost in the transition from the Roblox Wiki to the DevHub, and I think it would be better if this information was defined from a single source of truth, rather than being tacked on using hacks (as was done on the wiki). It would help a lot of newer developers, and could potentially improve the auto-complete functionality in Roblox Studio.

I hope this will at least be considered in the foreseeable future.

42 Likes
#2

I don’t think the “Humanoid humanoid” part would make much sense, as the Humanoid is an instance on a technical level, and there’s not a base class called Humanoid currently.

Now, InputObject gravity makes more sense than Instance gravity, as there’s no classes defined as “Gravity” to my knowledge.

Although, I feel as though the second argument would be more than enough information for most people to realize “Oh, I can’t put a BasePart as an argument for VehicleSeat:Sit().”

I agree that the auto complete system needs reworking as there’ll be times while coding where what I’m typing doesn’t even show up in the auto complete suggestions.