Naming of type objects #14

New issue

Open

opened 2025-04-10 17:41:27 +00:00 by glen · 1 comment

glen commented

2025-04-10 17:41:27 +00:00

Owner

For each type there will be the explicit conversion method, and the type object itself. These must be different, because generic types are callable as functions: Complex(BigNumber), for example, will produce a high-precision complex number type. This leads to some questions:

(A) I am unclear on whether we will need separate methods for type predicates: we will be able to write math.BigNumber.test(x) to determine if x is a BigNumber, so do we also need something like math.isBigNumber(x) ?

(B) I am pretty sure we want to stick with number, boolean, string, etc. as the explicit conversion methods. So to keep them closely associated, I was going to call the type objects Number, Boolean, String, etc. However, I just had a confusing bug because those names are already used in standard JavaScript (exactly for its explicit conversion operators). So I would like to use different names. What should they be?

For each type there will be the explicit conversion method, and the type object itself. These must be different, because generic types are callable as functions: `Complex(BigNumber)`, for example, will produce a high-precision complex number type. This leads to some questions: (A) I am unclear on whether we will need separate methods for type predicates: we will be able to write `math.BigNumber.test(x)` to determine if `x` is a BigNumber, so do we also need something like `math.isBigNumber(x)` ? (B) I am pretty sure we want to stick with `number`, `boolean`, `string`, etc. as the explicit conversion methods. So to keep them closely associated, I was going to call the type objects `Number`, `Boolean`, `String`, etc. However, I just had a confusing bug because those names are already used in standard JavaScript (exactly for _its_ explicit conversion operators). So I would like to use different names. What should they be?

glen added the

design

label 2025-04-10 17:41:34 +00:00

glen commented

2025-04-10 17:46:26 +00:00

Author

Owner

For now in the prototype I am going to:

(A) assume the answer is no, we don't need type predicates aside from TheType.test(x)

(B) name type objects corresponding to built-in types (only), where the preferred type object name is already in use, by adding a T suffix to that: NumberT, BooleanT, etc.

However, I would definitely be happy to have feedback on these issues, and will have no issues changing over to any better system should we come up with one.

For now in the prototype I am going to: (A) assume the answer is no, we don't need type predicates aside from `TheType.test(x)` (B) name type objects corresponding to built-in types (only), where the preferred type object name is already in use, by adding a `T` suffix to that: `NumberT`, `BooleanT`, etc. However, I would definitely be happy to have feedback on these issues, and will have no issues changing over to any better system should we come up with one.