Giulio Canti

> I'll try to convert the types to classes in another branch and see if there are benefits. I put up a branch (`types-as-classes`), no crucial benefits so far

> It's worth noting that the signature of validate > > ``` > (value: mixed, context: Context) => ValidationResult > ``` > > could theoretically allow for transformations while validating...

Ok, here you can find an implementation of the idea above: [branch validate](https://github.com/gcanti/flow-runtime/tree/validate) Seems to work pretty well, you can do ``` js import type { Type } from 'flow-runtime'...

@ivan-kleshnin not sure, do you mean something like this? ``` js import qs from 'querystring' const querystringBoolean: Type = { name: 'querystringBoolean', validate: (v, c) => t.chain(s => { if...

The thing I like the most of this implementation is that really honours the signature of `validate` (no more weird "validate MUST return value if validation succeeded" comment), you are...

@ivan-kleshnin in my example it comes from the `'querystring'` package

> or should it be usable as is with some sort of tcomb flow-runtime integration @minedeljkovic something like this should work (and the additional computation should be negligible) ```js import...

> In the meantime, I discovered what a great job you did with tcomb flow defs @minedeljkovic Ah thanks for the feedback! I'm glad is helpful, I've "lost" several hours...

> it's a kind of "obsession" in order to get the ultimate goal: having a single source of truth, the types This is also the reason why I'm studying full...

> Will this implementation replace the one with inj/prj? If we go the fantasy-land route then yes `inj/prj` are replaced by `new / this.value` (when possible, for example the module...