4 ms·

Weird - using constant string discriminators feel very natural and normal to me in Typescript. What do other languages do without them?

refulgentis 4y ago
Most model it as an actual enum, if backed by strings. Typescript, by comparison, requires being able to indicate a type just from a string argument
- esprehn 4y ago
  Allowing literal strings and type aliases of unions of strings to represent enums doesn't seem unreasonable. It's the same concept as many other languages with some extra quotes, ex. https://ocaml.org/docs/data-types#a-simple-custom-type https://ocaml.org/docs/data-types#a-simple-custom-type
  - deleted 4y ago
    [deleted]
- wruza 4y ago
  This doesn’t change anything: foo(get_some_myenum_value(), …) {type:get_another(), …} These are as unguessable as if myenum was a string.
- madeofpalk 4y ago
  Hmm. That doesn't feel like much of a difference to me?
  - refulgentis 4y ago
    It's huge? I'm really confused lol. I write in Dart/Java/C++/ObjC/TS regularly to maintain a cross-platform library and this is a massive difference from every typechecker in any other language, much less the narrower thing of if the idea of reifying random strings into an enum is a novel feature. I get a very strong sense from the thread that people are talking past eachother, somehow.
goto11 4y ago
The event type could just be exposed as a regular property so you could write `element.onclick.add((ev => ...)` so you would get static typing without any need for magic strings. Magic string are use all over JavaScript for different purposes. For example createElement('P') could just be new PHtmlElement() ... In other cases magic strings could be replaced with enums.
- madeofpalk 4y ago
  Changing Javascript is explicitly out of scope for Typescript. I was curious how other languages did discriminators in a way that makes Typescript's feel alien. Just having different functions doesn't really tackle that.
  - deleted 4y ago
    [deleted]
  - goto11 4y ago
    The pattern I'm most familiar with is using type constructors: type Shape = Square Int | Circle Int and then pattern matching: print (Square size) = .. print (Circle radius) = ... In Typescript this would be something like: type Shape = { type: 'square', size: number } | { type: 'circle', radius: number } And string matching for type narrowing: function print(shape: Shape) { if (shape.type === 'square) { ... } else if (shape.type === 'square) { ... } } The TypeScript approach is comparatively weird and verbose but also pretty clever since it doesn't require any change to the core language. It also have some pitfalls, e.g. you can write: print({type: 'square', size: 10}); But you cant write: const x = {type: 'square', size: 10}; print(x); <-- type error You have to write: const x = {type: 'square' as const, size: 10}; print(x); Things like this just complicates the type system and type inference.

refulgentis 4y ago

Most model it as an actual enum, if backed by strings. Typescript, by comparison, requires being able to indicate a type just from a string argument

esprehn 4y ago
Allowing literal strings and type aliases of unions of strings to represent enums doesn't seem unreasonable. It's the same concept as many other languages with some extra quotes, ex. https://ocaml.org/docs/data-types#a-simple-custom-type https://ocaml.org/docs/data-types#a-simple-custom-type
- deleted 4y ago
  [deleted]
wruza 4y ago
This doesn’t change anything: foo(get_some_myenum_value(), …) {type:get_another(), …} These are as unguessable as if myenum was a string.
madeofpalk 4y ago
Hmm. That doesn't feel like much of a difference to me?
- refulgentis 4y ago
  It's huge? I'm really confused lol. I write in Dart/Java/C++/ObjC/TS regularly to maintain a cross-platform library and this is a massive difference from every typechecker in any other language, much less the narrower thing of if the idea of reifying random strings into an enum is a novel feature. I get a very strong sense from the thread that people are talking past eachother, somehow.

goto11 4y ago

The event type could just be exposed as a regular property so you could write `element.onclick.add((ev => ...)` so you would get static typing without any need for magic strings. Magic string are use all over JavaScript for different purposes. For example createElement('P') could just be new PHtmlElement() ... In other cases magic strings could be replaced with enums.

madeofpalk 4y ago
Changing Javascript is explicitly out of scope for Typescript. I was curious how other languages did discriminators in a way that makes Typescript's feel alien. Just having different functions doesn't really tackle that.
- deleted 4y ago
  [deleted]
- goto11 4y ago
  The pattern I'm most familiar with is using type constructors: type Shape = Square Int | Circle Int and then pattern matching: print (Square size) = .. print (Circle radius) = ... In Typescript this would be something like: type Shape = { type: 'square', size: number } | { type: 'circle', radius: number } And string matching for type narrowing: function print(shape: Shape) { if (shape.type === 'square) { ... } else if (shape.type === 'square) { ... } } The TypeScript approach is comparatively weird and verbose but also pretty clever since it doesn't require any change to the core language. It also have some pitfalls, e.g. you can write: print({type: 'square', size: 10}); But you cant write: const x = {type: 'square', size: 10}; print(x); <-- type error You have to write: const x = {type: 'square' as const, size: 10}; print(x); Things like this just complicates the type system and type inference.