In the API dump, the “Object” type was used to indicate some kind of instance. In the latest update, properties of this type were changed to show the class name instead (ObjectValue.Value accepts an Instance, Model.PrimaryPart accepts a BasePart, etc). Types that are enums already follow a similar pattern; instead of displaying a generic type like “Enum”, the name of the enum is shown instead.
This change has introduced several conflicts with types in the API dump. Because class names, enum names, and names of structured types are now all used to indicate a type, several names have become ambiguous:
Button (class or enum)
Platform (class or enum)
Status (class or enum)
Thankfully, reference pages on the wiki are namespaced (class pages have a “Class” prefix, and enum pages have an “Enum” prefix). However, there are still problems with linking a type to its correct page. To resolve this, the API dump should follow a pattern similar to the wiki: when a type is meant to indicate a class or an enum, it should be given some kind of prefix, such as Class: or Enum:. This would resolve any conflicts that occur now and in the future.
I figured something like this was going to come up. I’ll mention it internally.
If we make such a change, will it break your tokenizer code that we’re using on the wiki?
Are you suggesting that we prefix property types with Class: or Enum: in the dump? Would just Class: be sufficient for now? (I’d like to minimize the diff delta)
The lexType function would have to be modified. Here’s something I came up with without looking into it too much:
local function lexType()
if data:sub(i,i+5) == "Class:" then
i = i + 6
return "Class:" .. lexName()
elseif data:sub(i,i+4) == "Enum:" then
i = i + 5
return "Enum:" .. lexName()
end
return lexWord()
end
I don’t remember if class/enum names are as complex as they once where, so this may be more simple/more generic.
Applying it to whatever changes were made in the last update (class names on property types) would solve the issue for now. Ideally, enums would also be namespaced, and it would be applied to anywhere a type name is emitted.
Could this use Instance: instead of Class: ? Technically, Color3, Vector3, etc. are classes too, right? These things are specifically Instances, not just classes.