This “info + one method that does everything” idea is the step in the right direction, but alas, there are problems with it
We have two methods with a similar architecture.
Workspace:Raycast
TweenService:Create
These two methods take in datatypes that (TweenInfo
for TweenService:Create
and RaycastParams
for Workspace:Raycast
)
However, now we have TeleportService:TeleportAsync
that takes in a TeleportOptions
instance?
So right now, in the Roblox API we have
TweenInfo
- A dataType that is immutable, so its information is passed through the constructor (REALLY BAD IDEA BTW).
RaycastParams
- A dataType that is mutable (which solves the problem with TweenInfo
). You set its information through the .
operator. (I’m not 100% sure about this so correct me if I’m wrong) The FilterDescendantsInstances
table is immutable. This is kinda awkward since I expect to use table.insert
or table.remove
onto the table. Again, it is sort of creating an inconsistency between what I expect a table to be (+ what functionality it has) and what RaycastParams says it should be. Again, correct me if I’m wrong though because I’m not 100% if the table is immutable.
TeleportOptions
- An Instance. Adds bloat to the TeleportOptions class since it’s inherited. For example, you would have methods such as :ClearAllChildren()
or properties such as Name
(I mean, do you REALLY have to set the name of your teleportOptions instance?) when you don’t really need it. (sorry the blurred stuff was false information, thanks BulldThomas for correcting me) When I don’t need this instance, I’m going to have to destroy it (the Tween class also has this problem where inexperienced developers just toss away the instance instead of destroying it whenever it isn’t needed).
Inconsistincies
Inconsistent Types: two out of the three is a dataType, but now TeleportOptions is an Instance??
Inconsistent Naming: We got xInfo vs. xParams vs. xOptions
Inconsistent paramater ordering: Workspace:Raycast
and TeleportService:TeleportAsync
has consistent ordering (origin, direction, raycastParams)
and (placeId, players, teleportOptions)
, but
TweenService:Create
has (instance, tweenInfo, table)
instead of (instance, table, tweenInfo)
Now do you see the problem? How can roblox expect new developers to pick up this engine easily if there are different ways to do the “info/params/options + one method that does everything” architecture.
You could ask, “Why does this matter?” Well, I have a feeling that the Region3
API + the Terrain
API will go down this route (and maybe the Widgets too?). However, they cannot continue if they don’t stick to one idea/style. Personally, Roblox should’ve thought this through before releasing the new API at all, because, now they have to deprecate again (and it sucks to learn something twice). Roblox already has it’s own mess and I’m glad they’re cleaning it up, but the way things are looking right now is not (IMO) going to work out for the future