Align Typescript & Runtype names

[johngeorgewright]

I understand this request is somewhat controversial, so I'm expecting some resistance, and that is totally reasonable. I'm sure you have thought long and hard about your naming conventions, but as I foresee a major release coming up, I thought it's a good time to chuck this spanner in the works and see if there's anyone else that feels the same.

I'm slowly bringing in the runtypes package in to our development process, at my place of work, as I love it's API and the codebase is easy to work with. However, 1 thing that has initially caused some confusion in my team (especially those new to Typescript) is the naming of Record & Dictionary.

Because Typescript has already chosen to use a type Record in a similar way to what you've chosen to name Dictionary, and you've chosen to use Record as a kind of Object validator, it seems there could be something more obvious and consistent.

How would you feel about using Object instead of Record & Record instead of Dictionary?

import { Object, Record, Number, String } from 'runtypes'

const a = Object({ foo: 'bar' })

const b = Record(String, Number) // I've also swapped the key/value parameters here to match typescript

This could well be considered more confusing, now that the community is used to the current naming, however, a part of me thinks it would be easier to get on board with if it was more aligned with Typescript.

Food for thought.

[yuhr]

Yeahhh this is what I've been thinking for a long time, I'm glad to see you have provided some momentum. Generally speaking changing names of APIs could be a huge surprise to users and requires intermediate deprecation notices, but this time it would apparently be a quite reasonable change.

There are some remaining tasks which should be done until v7, so we shall wait to seek for any resistive opinions in this issue. If no one comes, we'll introduce this change in v7.

[TheMeteoRain]

I would also like to add that we are forced to use String / Number / Boolean (notice first letter capitalized). TypeScript advices us to use only lower case versions (https://www.typescriptlang.org/docs/handbook/basic-types.html#about-number-string-boolean-symbol-and-object). This can be seen as very odd from perspective of new developers in projects. They are taught to NOT use capilatized versions.

I don't know if there can be done anything. Best case would be to let us keep using those same types that TypeScript wants us and extract guard, check etc. methods to somewhere else. Other solution is to do a named import import * as Rt from 'runtypes'. So people always see where those String / Boolean etc. helpers come from.

Just wanted to throw my .5cents. No expectations.

[ibezkrovnyi]

Meaning	Current naming	Proposed naming	TypeScript naming	JavaScript naming	Used in discussions in our team and between teams
Record with key-value type pairs known at compile-time	Record	Object	Record	Object	Record or Object
Dictionary or associative array or map	Dictionary	Record	Record	Object or Map	Dictionary or Object

I'm voting to keep current naming - it is accurate, comes from Data Structures theory and everyone (at least I have such experience) clearly understands the meaning - this is important additional benefit in communication with non-typescript devs: javascript and java devs, managers.

[yuhr]

TypeScript advices us to use only lower case versions (https://www.typescriptlang.org/docs/handbook/basic-types.html#about-number-string-boolean-symbol-and-object).

That is just for TypeScript's intrinsic static types, but not for JS-level runtime objects. I understand the capitalized runtypes might be confusing about that, but I believe the difference between them is one of the first thing TS developers must learn. I think the best solution not to confuse them is to use named import, as you said.

I'm voting to keep current naming - it is accurate, comes from Data Structures theory and everyone (at least I have such experience) clearly understands the meaning - this is important additional benefit in communication with non-typescript devs: javascript and java devs, managers.

Good catch. Though I think your table is a bit wrong at TypeScript naming; the first row must be "object". Records in TS are simple index-signatured objects, being similar concept to Maps rather. Actually I'm not down for the TS's naming convention in favor of theoretical studies, but this has already been common naming in TS's community, unfortunately. Basically, runtypes has an implicit goal to reflect TS's design, in order to minimize surprises to TS developers.

Although, maybe leaving Dictionary as an alias to the proposed Record would be a valid option...?