Open doodadjs opened 8 years ago
So I suggest :
Number Boolean String Object Symbol Int8/16/32/64 UInt8/16/32/64 BigInt Float16/32/64/80/128 Decimal32/64/128 Boolean8x16/16x8/32x4/64x2/8x32/16x16/32x8/64x4 Int8x16/16x8/32x4/64x2/8x32/16x16/32x8/64x4 UInt8x16/16x8/32x4/64x2/8x32/16x16/32x8/64x4 Float32x4/64x2/32x8/64x4 Rational Complex Type void
Note that "void" is a special keyword. And "Type" replaces "any".
Well not all the types have a parse function. I originally thought about a base type, but each type has a slightly different parse signature having radix or not for example. Some of the function like the SIMD types don't parse strings at all.
@sirisian Yes, I suggest a base type named "Type" (or whatever you want). The "parse" function was an example, and is not mandatory. Each type can have their own members, plus those of "Type"
Will need to come back to this when I, or others, can think of actual members for such a base class. I get where you're coming from, but I can't really see any benefits other than simply saying that "any" is a base class of all the types. There are no methods in any of my notes that would go into such a base class. Adding such a spec note would mean nothing for implementers other than adding words to the spec.
Also I should point out I've actively stayed away from the word "Type" since it's a very generic word that programmers might want to use in their own code. The keyword "any" was used because it's very readable. When a beginner sees x:any they'll read "The type for x is 'any'." which is how every such statement is read. For example, x:uint8 is "The type for x is 'uint8'". x:type would read "The type for x is 'type'" which is awkward. The main goal with the syntax proposed is consistency everywhere.
@sirisian Yeah, the important thing is I'd like to avoid primitive types and "typeof". With the incoming of classes, I wish JS will be more object-oriented. I wish to be able to do "value instanceof UInt32" and for every type under JS. For the moment, type detection is a nightmare.
Ideally I'd like both to work intuitively. A typeof returns a string and instanceof compares a type. Thanks for bringing instanceof since I don't have a section on it. I'll add an instanceof section like:
if (value instanceof uint8) {}
if (value instanceof (uint8):uint8) {}
Does that seem sufficient?
I don't understand the second one. Can you explain ?
Ok, I got it.
More verbosely by the way:
value instanceof (uint8):uint8
is:
Object.getPrototypeOf(value) === ((uint8):uint8).prototype
Will need to think about this a bit, but I'd like for that to work somehow comparing just the signatures.
Maybe more like this, to respect the prototypes chain :
((uint8):uint8).prototype.isPrototypeOf(value)
I'm not sure that function signatures can fit with types. Yes, they are part of the declaration of a function, but should the signature itself be a type ? That force the runtime to generate them while they are declared... Maybe something like :
Function.hasSignature(myFunc, "(uint8):uint8")
EDIT:
or
myFunc [some keyword] (uint8):uint8
I opt for "use stricter" to change the behavior of "typeof", so :
typeof myFunc === "(uint8):uint8"
That's already part of the spec?
Yeah I know. I had the feeling it was unsure.
I think it will be interesting to have a class by type all inheriting from a single class named Type. This way, we could have methods and properties related to them.
Example:
UInt8.parse(s:String) UInt8.prototype.toUInt32() ....