3 ms·

Maybe it is me, but I feel like mapped types and keyof are terrible features, and using them would be a sign of a bad design/architecture. In general, I don't

Maybe it is me, but I feel like mapped types and keyof are terrible features, and using them would be a sign of a bad design/architecture. In general, I don't think using a string that represents a static symbol (such as the name of a var, an attribute or a class) is a good idea. I try to keep a simple stack (Typescript + NPM at the moment), and I prefer to wait for Typescript to have the feature I want, than to install a new dependency (Babel, for example) to my project.

Etzos 10y ago
> In general, I don't think using a string that represents a static symbol (such as the name of a var, an attribute or a class) is a good idea. Why? (Genuine curiosity here, not trying to be hostile or anything like that)
klodolph 10y ago
I think there are two main kinds of developers who use TypeScript. Some developers come from traditional statically-typed languages, like C#/Java/C++/etc, and expect the language to conform to their idea of "good design". For these developers, "mapped types" are "not good design". Other developers come from JavaScript, Python, Ruby, or other duck-typed languages and think, "I know that this object is just a dictionary underneath it all, and I want a type system that lets me write code with that foundation." These developers want additional safety but they see traditional type systems as handcuffs. These are two very different styles of programming, and TypeScript does a fairly good job of serving both groups--it would have to, in order to be as successful as it is. There are a ton of useful JavaScript libraries out there which couldn't easily be rewritten to conform to some Java-style type system, and there are a ton of skilled Java/C#/C++ engineers out there who don't want their name on a bunch of cowboy code. I don't think this cultural division is going to go away any time soon, so it's in our best interest to believe that people in the "other camp" (whichever camp that is) are skilled and conscientious developers. I'm sure you've heard the arguments by dynamic language lovers who talk about how restrictive/slow/painful it is to write in a static type system, and I'm sure you're as tired of that argument as I am.
- stcredzero 10y ago
  I'm sure you've heard the arguments by dynamic language lovers who talk about how restrictive/slow/painful it is to write in a static type system, and I'm sure you're as tired of that argument as I am. At this point in time, it's a bit of a false dichotomy. It just amounts to a programming tool based on a form of meta-data. Of course people are going to have different ideas about the cost-benefit of that tooling. Of course, people are going to have differing opinions on how much of that tooling is worthwhile. Most of the problems with online discussions about this kind of tooling, come from people forgetting that it's just a discussion about tooling.
  - klodolph 10y ago
    I don't think this is a false dichotomy. There's definitely a spectrum between static and dynamic type systems, and plenty of people who identify with either camp. Calling it "tooling" changes the name of the problem, there are still people who will complain when they think the tooling is going in the wrong direction, and those complaints have merits because so many of us will be forced to write code in a style we don't like.
    - stcredzero 10y ago
      There's definitely a spectrum between static and dynamic type systems The key word is spectrum. and plenty of people who identify with either camp. What does it mean when people take something that's actually a spectrum, then divide that into two opposing camps? Does this sort of activity generally get public discourse closer to the truth, or farther away from it? It usually does the latter, in my experience. Hopefully, someone has set that knob to a position that works pretty well, and things work out. those complaints have merits because so many of us will be forced to write code in a style we don't like. Just who gets to write code in exactly the style that they like? From what I've seen, people generally make compromises, or they found the "perfect" job, or they are the one running the project, or they are going rogue and doing their own thing and introducing inconsistencies into a project's codebase.
      - 10y ago
daxfohl 10y ago
I assume you mean lookup types rather than mapped types; the latter has nothing to do with strings. In general, in application-facing code I think you're absolutely correct: using strings as lookups is a hack that should be discouraged. (Though sometimes it's convenient when dealing with other JS libraries). However the feature brings some strong metaprogramming abilities that wouldn't be possible otherwise. For instance I'd have to imagine that mapped types were implemented by using those features, and the ability to define types as variants of other types (beyond ordinary generics) is something very powerful. I'm primarily an F# user and have been begging for something like this there. The ability to define variations on record types (without and id/timestamp for inserts, with those fields otherwise; hashed/raw password fields for your various user records; etc) in a typesafe manner without a ton of repetition is a game changer.
ng12 10y ago
Simple example: keyof allows you to safely describe objects which only partially fit an interface. interface Values { foo: string, // etc... } let keys: keyOf Values function initialize(defaults: {[key: keys]: string}) {...} Now the defaults object can only contain valid keys from Values.

Etzos 10y ago

> In general, I don't think using a string that represents a static symbol (such as the name of a var, an attribute or a class) is a good idea. Why? (Genuine curiosity here, not trying to be hostile or anything like that)

klodolph 10y ago

I think there are two main kinds of developers who use TypeScript. Some developers come from traditional statically-typed languages, like C#/Java/C++/etc, and expect the language to conform to their idea of "good design". For these developers, "mapped types" are "not good design". Other developers come from JavaScript, Python, Ruby, or other duck-typed languages and think, "I know that this object is just a dictionary underneath it all, and I want a type system that lets me write code with that foundation." These developers want additional safety but they see traditional type systems as handcuffs. These are two very different styles of programming, and TypeScript does a fairly good job of serving both groups--it would have to, in order to be as successful as it is. There are a ton of useful JavaScript libraries out there which couldn't easily be rewritten to conform to some Java-style type system, and there are a ton of skilled Java/C#/C++ engineers out there who don't want their name on a bunch of cowboy code. I don't think this cultural division is going to go away any time soon, so it's in our best interest to believe that people in the "other camp" (whichever camp that is) are skilled and conscientious developers. I'm sure you've heard the arguments by dynamic language lovers who talk about how restrictive/slow/painful it is to write in a static type system, and I'm sure you're as tired of that argument as I am.

stcredzero 10y ago
I'm sure you've heard the arguments by dynamic language lovers who talk about how restrictive/slow/painful it is to write in a static type system, and I'm sure you're as tired of that argument as I am. At this point in time, it's a bit of a false dichotomy. It just amounts to a programming tool based on a form of meta-data. Of course people are going to have different ideas about the cost-benefit of that tooling. Of course, people are going to have differing opinions on how much of that tooling is worthwhile. Most of the problems with online discussions about this kind of tooling, come from people forgetting that it's just a discussion about tooling.
- klodolph 10y ago
  I don't think this is a false dichotomy. There's definitely a spectrum between static and dynamic type systems, and plenty of people who identify with either camp. Calling it "tooling" changes the name of the problem, there are still people who will complain when they think the tooling is going in the wrong direction, and those complaints have merits because so many of us will be forced to write code in a style we don't like.
  - stcredzero 10y ago
    There's definitely a spectrum between static and dynamic type systems The key word is spectrum. and plenty of people who identify with either camp. What does it mean when people take something that's actually a spectrum, then divide that into two opposing camps? Does this sort of activity generally get public discourse closer to the truth, or farther away from it? It usually does the latter, in my experience. Hopefully, someone has set that knob to a position that works pretty well, and things work out. those complaints have merits because so many of us will be forced to write code in a style we don't like. Just who gets to write code in exactly the style that they like? From what I've seen, people generally make compromises, or they found the "perfect" job, or they are the one running the project, or they are going rogue and doing their own thing and introducing inconsistencies into a project's codebase.
    - 10y ago

daxfohl 10y ago

I assume you mean lookup types rather than mapped types; the latter has nothing to do with strings. In general, in application-facing code I think you're absolutely correct: using strings as lookups is a hack that should be discouraged. (Though sometimes it's convenient when dealing with other JS libraries). However the feature brings some strong metaprogramming abilities that wouldn't be possible otherwise. For instance I'd have to imagine that mapped types were implemented by using those features, and the ability to define types as variants of other types (beyond ordinary generics) is something very powerful. I'm primarily an F# user and have been begging for something like this there. The ability to define variations on record types (without and id/timestamp for inserts, with those fields otherwise; hashed/raw password fields for your various user records; etc) in a typesafe manner without a ton of repetition is a game changer.

ng12 10y ago

Simple example: keyof allows you to safely describe objects which only partially fit an interface. interface Values { foo: string, // etc... } let keys: keyOf Values function initialize(defaults: {[key: keys]: string}) {...} Now the defaults object can only contain valid keys from Values.