add support for "type|otherType", e.g. "String|Buffer"

[mvayngrib]

add support for "type|otherType", e.g. "String|Buffer"

[dcousens]

@mvayngrib I agree that can be really useful, but it means the complexity of the modue will grow significantly to handle it.

[mvayngrib]

i took a whack at it, still looks pretty simple and only a couple of lines longer, let me know what you think https://github.com/mvayngrib/typeforce/tree/typeOpts

[dcousens]

@mvayngrib I'd rather not penalize every call with a need to check over the string for | characters, even if we made use of regex this is probably way slower.

Definitely need to test that though.

If we do support this, unless the implementation is on-par, perhaps we could include it as a sub-module?

[mvayngrib]

@dcousens good point, I wasn't really thinking about performance. Let's leave it be for now, see if anyone else cares about this feature

[dcousens]

@mvayngrib what are your thoughts on the following style of syntax (pick and choose, I just brain dumped a few ideas here):

typeforce({
  foo: typeforce.maybe("String") || typeforce.String.maybe,
  bar: "Number" || typeforce.Number,
  fizz: typeforce.any(["String", "Number", { b: "String" }, typeforce.value(3.14)]),
  object: typeforce.instanceOf(CustomType)
}, value)

This would allow us to handle Maybe types better than using ?, and sum types with oneOf or some such.

The string typing is a bit limiting (in both performance/features) at the moment and could probably be sped up with typeforce.String or String objects.

I'd like to keep some easily serializable types though for JSON type schemas, so maybe the same types we have now, but with functions are callable.

[dcousens]

@rubensayshi any thoughts?

[dcousens]

Added in eec6969

Syntax:

typeforce.oneOf(["String", "Number", { b: "String" }, typeforce.value(3.14)]),

[mvayngrib]

@dcousens sorry, I'm a bit slow. I realize I opened this issue, but I kind of changed my mind since then :)

I like and appreciate the flexibility. However, I now realize that it encourages developers to write their methods in a hard to use and maintain (if flexible) way. What I hate most about node's core APIs is this kind of stuff:

from dgram:

socket.bind(port[, address][, callback])
socket.bind(options[, callback])

very flexible, and ultimately a pain. I'd much rather they just support the 2nd one

These days, I'm still using typeforce and almost always in this use case:

typeforce({
  msg: 'Buffer',
  to: 'String',
  public: '?Boolean'
}, options)

If it gets more complicated than that, I rewrite the method.

[dcousens]

Wholeheartedly agree with you.
However, that doesn't mean sum types can't still be useful.
For example, I could now specify the following:

function Buffer256bit (v) { return Buffer.isBuffer(v) && v.length == 32 }
function Buffer128bit (v) { return Buffer.isBuffer(v) && v.length == 16 }

var inputBuffer = "oops"
typeforce(typeforce.oneOf(Buffer256bit, Buffer128bit),  inputBuffer)
// Expected Buffer256bit|Buffer128bit, got String "oops"

A bit contrived in this example, but I think the use case speaks for itself in that you can use typing in even stricter ways using this syntax.