As a Roblox developer, it is currently too hard to remember that PartType is the enum for the BasePart.Shape property. This is the only enum I consistently forget, since most other enums match the name of their associated property. Furthermore, I consistently forget that the PartType for a sphere is PartType.Ball instead of PartType.Sphere.
If Roblox is able to address this issue, it would improve my development experience because I would not draw a blank every time I create a sphere or cylinder in code, which I do very frequently.
I can also +1 to this. I keep instinctively try to write Enum.Shape, Enum.ShapeType, or Enum.ShapePart instead and have to look up the enum so much that it has become comical.
Deprecate BasePart.Shape and add an alias as BasePart.PartType
Deprecate Enum.PartType and add an alias as Enum.Shape
Do nothing
Options 1 & 2 won’t break anything, but they would obligate the need to update codebases as so things stay consistent. If a change should take place, however, I would prefer Option 2 as it seems more reasonable to add an extra enum instead of a new property.
I would chalk that up to bad practice. Data types beyond strings exist for a reason. Just because something can be implicitly casted doesn’t mean it’s fine to do in anything other than exceptional circumstances.
We sympathize with the name being hard to remember (it’s really old), but this is unfortunately a surprisingly difficult issue to fix.
The best way to do this is by creating Enum.Shape, where Enum.Shape == Enum.PartType. However, this is as far as I know unprecedented, and our system isn’t really built for it.
We can’t make it a separate enum that maps from Enum.PartType, for two reasons that are similar to each other:
if part.Shape == Enum.PartType.Ball then
…and…
local partShapes = { [Enum.PartType.Ball] = "ball" }
print(partShapes[part.Shape]) -- Would give "ball" today, but "nil" with a naive enum implementation.
(The interesting part about case 2 is that we can’t hack around it with __eq and friends like the first case).
The more straight forward path is to deprecate Enum.PartTypeandPart.Shape in favor of something else with the new enum. This would be fine if the property name was something whack too, but Shape is a pretty darn good name.
Basically, having Enum.Shape == Enum.PartType would fix this, but it’s really hard to do with our code right now.
Jokes aside, it has been the other way around for me. Sphere is sometimes easier to remember than Ball, but it doesn’t matter. What could possibly be done is using a post-process script (on the dev source code side) to, when compiling the application, replace the string occurrence of Sphere with Ball. There!
