Use consistent naming for Remote/Bindable objects

As a developer, it is annoying to use Bindable/Remote objects, as since the naming of their members is inconsistent, I always have to double check the wiki. Here are the members in question:


As you can see, BindableEvent.Event does not follow the same convention as the rest. I don’t care which convention they all follow, but we should pick a convention and follow it consistently for all of these objects. Please redirect all suggestions of which convention we should use to this feature request. This thread is intended to discuss the lack of a consistent convention – not what it should be.


Why are client/server events separated anyway? Surely they can just replace them with “OnInvoke” and “OnEvent” and have them behave differently to the client/server.

Probably for the sole purpose of being explicit. If you saw:

communicatorEvent.OnEvent:connect(function(arg1, arg2, arg3)

there’d be no way to know whether that was meant to be used serverside or clientside. Looking at which script it’s in is an option, but modules can be required by both the server and the client, so it’d be impossible to tell there. Even if it was in a server script, explicitly stating the event’s purpose in the name makes it easier to process, as implicitly we’d have to jump through a few mental hoops to realize the behavior every time we glanced over it.

Given that Bindables predate Remotes, it would be Remotes that aren’t following the convention (who cares, though).

How should the backwards incompatibility of changing a member name be handled?

Is it even worth it? Do developers really use Bindables and Remotes in similar enough ways that this is a problem? One type certainly isn’t a drop-in replacement for the other. Some examples would help.

Personally, I no longer associate them as being analogous. RemoteEvents are just a means to communicate across peers. The idea of RemoteFunctions is cute, but unsafe (especially server->client), and should be avoided entirely. While Bindables have that aspect of communication between scripts, they don’t share the same nuances or practices associated with networking.

Deprecate old member. Add new one.

Yes. Regardless of how Bindable and Remote events are used, due to their (API) similarity, memories can get fuddled “I forgot – is it BindableEvents or RemoteEvents that use the On prefix?” “Oh, bindables have similar members to remotes right? I think I just remove server/client so it’d be OnEvent.”

Using bindables/remotes for the same purpose is not required for confusing their API members. I am intentionally not answering your question of use case of drop-ins and delving into a mostly-pedantic discussion because it isn’t exclusive to confusing API members.

I don’t really use RemoteFunctions so I wouldn’t care what we do with them one way or the other, but they’re not deprecated so they should be kept up to speed with the rest of the API. If you think they should be deprecated, that would be more appropriate in a dedicated feature request.


So far, we have one known case of this happening. Since a name change would create legacy cruft (deprecated member), it ought to be justified. If we can determine that enough developers also have this particular problem, then it would be worth doing.

“There needs to be enough developers to warrant change”

As is true with every feature request. This is partially what thread likes gauge.

We can add OnEvent to RemoteEvent and fire both events internally.

1 Like