When I first saw the readme, I did a double-take at this:
xtype(5) === 'positive_integer'; // Value is number, positive and integer
xtype(5) === 'int+'; // 'int+' is same as 'positive_integer'
Unless there's some new ES6 magic I haven't heard about, Javascript does NOT permit operator overloading, so it should be impossible for an object to be === to more than one distinct string!
Looking more closely, the library seems to be quite useful, has a test suite, and the real syntax is xtype.is(5, 'int+'). But if that's the case, just say that! Don't pass off some nonworking pseudocode as real JS code in your readme! There's a saying "where there's smoke, there's fire," and if there's this egregious a deception in your documentation, it makes me hesitant to depend on the library!
There is no pseudo-code in the documentation. All of the documentation code executes as documented.
The library works with type names in two naming modes - default and compact. The default name scheme uses the full type names, such as 'positive_integer', while the compact name scheme uses compact names, such as 'int+' for 'positive_integer'.
You can only be in one mode or the other at any one time. You can switch between the two using the xtype.setOptions method:
xtype(5); // 'positive_integer'
// Switch to compact name scheme:
xtype.setOptions({nameScheme:'compact'});
xtype(5); // 'int+'
This looks incredibly useful and I appreciate the focus on performance. I often avoid writing helpers for type checking edge cases due to performance concerns, but you've done the hard work for me. Thank you.
Thanks. I developed and used it as a utility in a bigger library that worked heavily with types, but later exported it to its own project so I could share it, after I realized how useful it was, even stand-alone.
It is very highly optimized, as performance was of critical importance.
Looking more closely, the library seems to be quite useful, has a test suite, and the real syntax is xtype.is(5, 'int+'). But if that's the case, just say that! Don't pass off some nonworking pseudocode as real JS code in your readme! There's a saying "where there's smoke, there's fire," and if there's this egregious a deception in your documentation, it makes me hesitant to depend on the library!