How does that even remotely applies to the "is positive integer" test, and even more so to "it's positive" and "it's integer"?
What's next? is-bigger-than-5? word-starts-with-capital-letter? add-1-to-a-number?
Having pre-written modules that account for all edge cases that have been battle-tested by hundreds, thousands, or even millions of users does have merit.
The main problem here is with the Javascript language, which makes code evolve to things like 'is-positive-integer'.
The issue I have with this is readability. Type '>' and I know exactly what it does, I know what implicit conversions are involved, and how it would react to a null object. Type 'isPositiveInteger' and I need to check. I can not read your code fluently anymore.
Well played.
We're doing a GSoC for efficient templating of real number though.
You wouldn't write: "I saw Five of my friends last night."
This seems to be a very common example in educational materials about how to create a function in some programming language. Perhaps they should all be prefaced with "NOTE: you should not actually make such a function, because its triviality means that every time you use it you will be increasing the complexity of your code", or a longer discussion on when abstraction in general is appropriate and when it is not.
Ditto for any other abstraction --- I've found there's too much of an "abstraction is good so use it whenever you can" theme in a lot of programming/software design books and not enough "why abstraction can be bad" sort of discussion, which then leads to the "you can never have too much" mentality and the resultant explosion of monstrous complexity. Apparently, trusting the reader to think about the negatives and exercise discretion didn't work so well...
That's the whole point. If you use is-positive-integer, you won't have to think about the negatives!
Of course we have a number of packages that are truly trivial and should probably be inlined. Npm is a completely open platform. Anyone can upload any module they feel like. That doesn't mean anyone else will feel the need to use them.
I think you'll find that the vast majority of small modules that are widely used are ones that also cover obscure corner cases and do benefit from widespread use and testing.
module.exports = exec("===");
module.exports = bigger(a, b){return a > b};
module.exports = () => return "than";
module.exports = (a) => a.search('ABCD...');
.. or something like that. These are all plugins of course.
I feel like you haven't spent enough time with Unicode.
You're welcome!
Adding another module with a method does not fix the original problem, it just creates more problems for other people to solve.
> isCapital("שלום");
true
> isCapital("1");
true
> isCapital('\uD83D\uDE00'); // Smiling emoji
true
> isCapital(\u279B); // Right-facing arrow
true
> isCapital("\u061Casd"); //Bidirectional control character
true
> isCapital(" ");
true
Actually, it just means that if you're wondering "if this word starts with a capital", you're asking a wrong question. Instead, you should be asking "if this word is a valid generic name", or "is this word a start of a new sentence", and implement these semantic queries in a language-specific way.
startsWithCapitalLetter("!") == true
edit: fortunately there's an npm modules you can included to fix it...
Why not both? If you just want one part of a module, you can just import the dependency directly, if you want a whole core lib, you can do that.
Some people really like underscore and import that. I use ES6/7 functions for the most part, but underscore has some useful things I can import on their own.
Someone might do something like ~~n to truncate a float. That works fine until you go above 32 bits. Math.trunc should be used instead. Someone might do something like n >>> 0 === n, and using any bitwise operators will always bake in the assumption that the number is 32 bits. Do you treat negative 0 as a negative integer? Detecting negative 0 is hairy. So, to avoid bad patterns, it makes sense.
For is-bigger-than-5(x), x > 5 is not hairy. For add-1-to-a-number(n), n + 1 is not hairy.
For word-starts-with-capital-letter(word)? That one is actually pretty hairy. There are programmers that would write a regular expression /^[A-Z]/, or check the charCode of the first character being within the A-Z range, amongst other solutions. An appropriate solution, however, would be (typeof word == "string" && word.length && word[0] == word[0].toUpperCase() && word[0].toUpperCase() != word[0].toLowerCase()), because the toUpperCase and toLowerCase methods are unicode-aware, and presently you can't access unicode properties using Javascript's flavor of regular expressions.
i++