RobloxType function

Feature Requests Engine Features
#21

What does the final implementation look like? Namely, how the sub-typing thing is handled.

#22

It’s called typeof, it returns the name of the type. If it isn’t a roblox type it will return type()'s return value instead. I’m not sure what you mean by sub-typing.

1 Like
#23

If it’s an instance, does typeof return “Instance” or the instance’s ClassName? Preferably it’d be just “Instance”. If it’s the ClassName, I can’t easily tell if it’s an Instance or not using typeof, but if it returns “Instance”, I can distinguish between instances and other ROBLOX data types, while at the same time being able to tell what kind of instance it is by doing typeof(obj) == “Instance” and obj.ClassName

#24

Either “Object” or “Instance”, I don’t remember which one atm

1 Like
#25

Instance sounds more appropriate, so if it’s Object I’d recommend changing it before that’s no longer an option

1 Like
#26

If you look in the Object Browser or the API dump, the type’s name is Object. While I agree that “Instance” sounds better, I’d rather have typeof return “Object” to be consistent with the API.

You should reread the thread. Or at least this post. There’s also the subtyping section of my proposal. The motive is to keep Lua types separate from Roblox types to ensure that the typeof function remains forward compatible.

Also, how are enums and enum items being handled? My original proposal addresses enums, but it involves expanding their API a bit.

#27

Instances being denoted as Objects is backend diction that never sees the light of day. Returning Object instead of Instance would only create confusion.

#28

Looking back at the API, I now remember that multiple names are used:

  • “Instance” when it’s an argument to a function or event, or a return value of a function
  • “Object” when it’s a property
  • “Objects” when the value is a table of instances

So I guess Instance is probably fine. Perhaps it’s the API that needs fixing.

#29

There is no sub-typing behavior. It just tells you the type. I don’t see any reason why I would need to know if it’s a basic type or a roblox type. Enums return like:

print(typeof(Enum)) --> Enums
print(typeof(Enum.NormalId)) --> Enum
print(typeof(Enum.NormalId.Top)) --> EnumItem
3 Likes
#30

Got it. I suppose subtyping is unnecessary for lua types when you can just check type() before checking typeof().

One final question. How does typeof handle no value (e.g. typeof())? Does it throw an error like type(), or return a value, such as “void”?

#31

type(nil) returns nil

#32

He means no value at all, not even nil. (they’re different)

2 Likes
#33

typeof(game) returns “Object”
typeof() returns “no value”

Note that typeof() is distinct from typeof(nil). typeof(nil) will return “nil”.

#34

Can typeof() > “no value” be changed to an error to be consistent with type?
Can typeof(game) > “Object” be changed to “Instance” to be consistent with traditional (rather than backend) nomenclature / less confusing overall?

4 Likes
#35

I agree that typeof() should error but not the other suggestion.

#36

print(typeof(game))

  • Object
  • Instance
  • Show results

0 voters

#37

I’ve never been quite sure why “Instance” is the nomenclature used as opposed to “Object”. I would prefer to use Object as it makes more sense in this API than Instance.

I agree with this.

#38

Because Instance is used everywhere throughout the C++ side. It’s the base class for everything in the datamodel. 1x1x1x1 was the original Instance.