Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Although javascript is a weakly typed language, in some scenarios is needed to ensure the data type. Currently many node packages depend on helper functions, e.g, isNumber and isFunction.
It'd be interesting if there were built-in methods for that like Array.isArray. Something like Number.isNumber or Function.isFunction.
What do you guys think about this?
You should not worry much about such. There are already a lot of methods. For your query, you can use Number.isNaN for checking number and use typeof to know if the given variable is a function.
You can check the following answers:
Is there any function like IsNumeric in JavaScript to validate numbers?
How can I check if a javascript variable is function type?
Array is a collection. The collection might refer to [...] or {...} and this is why there's Array.isArray to check if the given collection is array or not. But there's no other way arround for differentiating the function and the number between themselves. And this is perfect reason the javascript should not have such function.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
When removing a property from an object, I've used the delete operator in the past. But when I had my code reviewed by a person with a CS background, they wanted me to find another way of removing the property because it was an "expensive" task (not sure what that means). Since I'm self taught I wanted to ask if deleting in Js is something I should consider using as last resort? I've looked at other responses within SO like this but couldn't find anything that makes reference to this.
No, it's not considered bad practice. It just depends on what you want to do,
Read this thread:
Garbage Collection and JavaScript "delete": Is this overkill/obfuscation, or a good practice?
The book "JavaScript, the Good Parts" by Douglas CrockFord says...
The delete operator can be used to remove a property from an object. It will remove a property from the object if it has one. It will not touch any of the objects in the proto-
type linkage.
I think you can use the Delete operator without worries. There are many other ways to remove a property from an object, but all they are more expensive in my opinion.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm using Typescript for a Node application and I love to fully use the power of Javascript with all the good stuff of Typescript. Line after line I took up the habit to chain functions, to use arrow functions, to user carrying and partial functions and so on.
What I really cannot understand is why the forEach function return void instead of something useful I can use to perform a chainable, just one-line and elegant piece of code.
My question is about the design considerations behind this choice that at first glance seems to be just annoying and the implications a return value can cause.
Because that's what forEach does. It's like a for loop; it isn't meant to evaluate to anything useful. It's intended to be used to carry out side effects using a function. If you need it for anything other than that purpose, it's the wrong tool for the job.
If you want a looping function that evaluates to something, use map or reduce instead. map will return a new list based on the old list, and reduce will return a reduced value from iterating over the list.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
In many languages, to find cosine, you use cos(x). But in JavaScript, you must use Math.cos(x). Why doesn't JavaScript spare us the 5 characters in Math., both making it easier to type and easier to read?
I have tried to Google this multiple times, and found no answers. Is there any practical reason for this that I have not yet found?
So far, there are three reasons I can think of:
The creators of JavaScript want to ensure that the math functions do not coincide with other functions users create (Like a function called 'cos()` that calculates, say, cosecant)
The creators of JavaScript thought that Math would make the code more readable
The creators of JavaScript perhaps didn't want any functions that have window as a parent (Though alert and prompt make this unlikely)
To hold the math functions without polluting the global namespace.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Lets say you needed a hardcoded list of strings (the question here is not whether or not you should hard-code things).
Is there a reason to prefer this:
var things = 'a b see'.split(' ');
over this:
var things = ['a', 'b', 'see'];
Pros of first approach:
Easier to refactor data from code. (String is not language specific)
Pros of second approach:
Less prone to error (what if your string has a space in it?)
Easier to format automatically (can and probably should separate each string by newline)
Easier to get data from alternate sources in the future.
Signals intent more clearly
Tiny bit more efficient
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Today I heard that a JavaScript object is no more than a plain dictionary (taking as a reference the python dictionary)
I think it's a wrong idea, but I did not know how to answer to that.
So, can you give me reasons why objects are not simple and dry dictionaries?
My first idea: prototypical inheritance.
...
Well, do dictionary items have an implicit this reference to the dictionary?
If not, then a Javascript object is a bit more than a plain dictionary.
As dystroy points out, this is created by using a function to create the object, so it is probably more of a closure around the object.
So in that case, yes, an object is probably very much a dictionary :/