Which naming convention is best for Remote/Bindable objects?

Feature Requests Engine Features
#1

BindableEvents, BindableFunctions, RemoteEvents, and RemoteFunctions are all pretty similar. Here are their listener API members:

RemoteFunction > OnServerInvoke, OnClientInvoke
RemoteEvent > OnServerEvent, OnClientEvent
BindableFunction > OnInvoke
BindableEvent > Event

We have mixed conventions here: BindableEvent is missing the On prefix, while the rest have it. If they were all changed to use the same convention, what should it be?

5 Likes
Use consistent naming for Remote/Bindable objects
#2

Or, alternatively, change OnClientEvent and OnServerEvent into ClientEvent and ServerEvent.

Or, if we’re going to be using ‘On’ then it should probably be OnClientFired, OnServerFired, and OnFired. Edit: Which becomes consistent with the *Function API: On*Invoke, Invoke*, On*Fired, Fire*. Then we’d just have to standardize their tenses (Invoke vs Invoked, Fire vs Fired).

#3

As far as I know, RemoteEvents, RemoteFunctions, BindableEvents, and BindableFunctions are some of the only classes to implement event names with On in them.

#4

Unless you’re looking to rewrite multiple parts of the API, the On prefix is normal, and changing it would be outside the scope of making BindableEvent consistent with similar objects. This goes for your tense change suggestion as well @Corecii.

1 Like
#5

Not sure. Lots of the API is just generally inconsistent. All over the place. Your fix is probably the simplest. :thumbsup:

#6

If we’re talking about names and confusion, here’s a similar problem:

  • RemoteEvent.OnServerEvent is an event generated by the server.
  • RemoteEvent.OnServerEvent is an event received by the server.

Given no other context, which one sounds correct?

3 Likes
#7

Why not just deprecate Bindables all together and allow the server to :Fire() which would act as a local event that only that local machine can listen to… like bindables basically.

#8

:uhh:

I mean, some naming is a bit confusing maybe, but the entire concept is useful.

1 Like
#9

Cause I use bindables in my entire framework, and wouldn’t be too happy in creating a pure Lua alternative.

As for API inconsistency, I’ve been taking the time to try and reimplement the whole “DataModel” in Lua via a easy to use ModukeScript. No where near done, but it cleans up the API and merges several services/etc. Might release demo soon.

EDIT: why is this relevant? Cause (no offense, nor do I blame them) ROBLOX doesn’t seem too interested in doing it themselves/officially

EDIT2: blaaaaarg typing on a tabletqqqqqqq

#10 
BindableFunction  :  Invoke  → OnInvoke
RemoteFunction    :  Invoke* → On*Invoke
BindableEvent     :  Fire    → Event
RemoteEvent       :  Fire*   → On*Event

Seems like that can be simplified…

BindableFunction  :  Invoke  →  Invoked
RemoteFunction    :  Invoke* → *Invoked
BindableEvent     :  Fire    →  Fired
RemoteEvent       :  Fire*   → *Fired