game.RunService as an alias to game["Run Service"]

Feature Requests Engine Features
#1

Similar to how the game.Workspace alias works, it would be nice to see game.RunService added.

For as long as I can remember, RunService has been named “Run Service” as a child of the DataModel (game). To preserve backwards compatibility, it cannot simply be renamed to “RunService”.

But an alias as a property of DataModel could fix this.

7 Likes
#2

This doesn’t seem useful, you should just use GetService to access services.

9 Likes
#3

In my own code, I do use GetService. This is more about API completeness and cleaning up inconsistencies.

Similar to the change of BodyGyro.cframe to BodyGyro.CFrame.

1 Like
#4

Adding this might encourage the bad practice of calling other services without using GetService.

4 Likes
#5

But…

	Property Object DataModel.Workspace [readonly]
	Property Object DataModel.lighting [deprecated] [readonly]
	Property Object DataModel.workspace [deprecated] [readonly]

those are literally the only 2 services that do this…

Should use :GetService() anyway, especially since some services don’t get instantiated until they’re requested (Teams(?) and TestService are the only ones I can come up for now)

#6

With “cleaning up consistencies”, I think he’s referring to how you can write game.Workspace, game.MarketplaceService, game.DataStoreService, etc, but for RunService you have to do game[“Run Service”] which is awkward over game.RunService.

2 Likes
#7

You are right that it would be about API completeness, but I think that in this case, it would be filling-in in the wrong direction.

#8

It’s the same as workspace.Fields.FieldA. Works great, unless one of these things is missing (or renamed). Lua-wise, I’ve grown up mostly in script builders, where it isn’t too uncommon for people to rename services to “deter skids” or something, so I might be a bit too biased. But then again, using GetService seems like a good practice, so eh…

#9

Sure but how great would it be that whenever I’m messing around in Studio, I could just write the intuitive “game.RunService.(…)” in the command bar rather than having to do “game[“Run Service”].(…)” which takes like twice as long to write due to the brackets… One can dream

1 Like
#10

I literally only use :GetService() (not even :service()), so eh.

I could easily add my JQuery CSS selector crap as a global, so I can do S("RunService"), but kind of unrelated to the thread’s (original) goal)

#11

AFAIK it’s impossible to automatically add globals to the command bar scope unless you’re using _G or shared.

#12

Can’t you just run A=B the first time?

(there’s also an “exploit” to get the global env, so could still use that if I cared much)

#13

Yes, you can manually but inconveniently type that into the command bar, diminishing its usefulness.

#14

There was this Feature Request for plugins to access the commandline’s environment. Would be nice if that ever gets implemented.

But on-topic: is this really necessary? (I would say no) It’s not a big inconvenience, as you don’t write code accessing RunService a dozen time a day.

#15

ya’ll need some shared.svc.RunService in your lives

The added convenience is minimal and the added utility is zero, so probably not.