A re-introduction to JavaScript(developer.mozilla.org) |
A re-introduction to JavaScript(developer.mozilla.org) |
IE users are probably used to getting a horrible user experience anyway. I'm sure they can cope with a few browser freezes/crashes every once in a while - They know how to take a beating :p
The article has gotten updates since then (check the history), but not many and not to the extent it probably needs. Not sure why it keeps getting linked.
Indeed IE's users are having terrible experience anyway, but let's just don't push FF and Chrome to their memory limits, just because we don't care with our code.
One of the best parts when I develop client-side web-apps is the debugging and looking close what the garbage collector is doing. For example : I usually don't use `delete` keyword, since I know it might create a node that GC's can't clear.
In the end a lot of people using the application would either have to restart during the day, use portable Firefox, which many actually did. Of course, there are/where many worse things in practice dealing with supporting IE<9 for relatively modern web applications. I'd still rather deal with that, than the v4 browser days.
Javascript is not a toy; toys are fun.
I just wanted to say that the behaviour of this 'nicer' idiom may not be what's expected - it stops iterating once it hits the first falsy value. I was quite excited actually when I first saw them idiom, until I quickly realized its limitations
+ "42"; // 42
Being a bit pedantic here, why not recommending the Number function which may be less obscure for beginners?
Number("42"); // 42el$ = $('#whatever'); el$.click( function() { el$.find("a").css("color", "red"); } );
In general, the only niggle is when you want a discrete integer value, where zero is an acceptable input, or a string that represents a number coerced into a number.. but anything else to be null. You have to single out falsy values that aren't zero in this case.
Other than that one niggle in practice, I've come to truly appreciate the expressive nature that JS actually offers in practice. The additional concepts added in terms of ES6 and ES7 are pretty welcome. Though in practice, I've moved very far away from trying to apply many OO patterns of classes, inheritance, etc in favor of basic object instances, and functions that can be combined/composed.
It's pretty nifty all around.
Consider the following:
.1 + .2 == .3 // false
Anyways, all you have to do is check if the absolute difference of the numbers is less than the epsilon:
var a = .1 + .2, b = .3, epsilon = .00001;
console.log(Math.abs(a-b)<epsilon); // true
var SCALE = 100; // 0.01
var a = 0+1 * SCALE; // e.g. 2.5 would be 2+5 * SCALE
var b = 0+2 * SCALE;
if (a + b == 0+3 * SCALE) {
// this will work...
}
console.log(a / SCALE);Homework: 1) Google for such; 2) see which one doesn't suck.
No it isn't. It has support for OO and you can choose to write code object-oriented if you wish. But equally you can disregard the OO bit quite happily and compose behaviour using closures instead.
None of my favourite JS libs are OO, it's a poor abstraction imho.
Along the same line but more in depth, I really like Cody Lindley's JavaScript Enlightenment:
[1]: 32-bit integers show up under the hood, in expressions such as `5000000000|0`. Both 0 and 5000000000 are precisely represented in JS's Number type, but you cannot (correctly) take a binary OR of the two.
It really isn't unique to JS, and there are several bignum libraries that can/will help.
Keep up the good work Mozilla.
edit: I see MANY people contributed! You can too! https://developer.mozilla.org/en-US/docs/Mozilla/Connect. It still would be cool if Eich could act as an "editor" to JS related articles!
Not to mention the suggestion you're talking about, which I bet would bite programmers for the reason you mention. Seems like a bad idiom, I've personally never seen it in the wild.
In fact, even `for` is likely an over-optimization. In nearly all JS code you can get away with just using `forEach` (or its friends).
Can't wait for ES6 to no longer be 'experimental', as I'd much prefer to use 'for..of' loops
I think there are still places where you need to do this (please correct me if wrong, or mention some other cases):
- when iterating over DOM nodelists in JS (why doesn't the browser cache this as well?)
- if using strlen in C/C++ (for the latter, you should use string.length() instead).
(Sure, IE<9 is a caveat, but all the Array iteration methods are the easiest things to shim and if you're targeting below IE9 chances are pretty good it's not the first shim you'd be using.)
“A nicer-looking but limited idiom is:”
MDN documentation is on a wiki. You can just edit the page.
It's the most confusing part about Javascript. This context, var foo scope, what? Why is this value not updating? undefined? What???
>>> class foo():
... def test(this, x):
... print this, x
...
>>> x = foo()
>>> x
<__main__.foo instance at 0xb71928ac>
>>> x.test(1)
<__main__.foo instance at 0xb71928ac> 1
>>> y = foo.test
>>> y(1)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unbound method test() must be called with foo instance as first argument (got int instance instead)
>>> y(x,1)
<__main__.foo instance at 0xb71928ac> 1
function foo() { }
foo.prototype.test = function(x) {
console.log(this, x);
}
var x = new foo();
x.test(1); // prints VM1061:4 foo {test: function} 1
var y = x.test;
y(1); // prints VM1061:4 Window {top: Window, window: Window, …} 1I simply don't ever need to think about it anymore.
And I don't just mean run-of-the-mill blub programmers who dabble in jQuery, I mean some of the best devs I've ever seen in any language. I had a self-proclaimed JS expert tell me that JS has integers and floats as distinct types. Even the people I work with every day who are fantastic did not know that function and array are not types.
Of course, things like `typeof` don't help the situation, so I don't put the blame squarely on programmers' shoulders. And obviously you can get a lot done without knowing that, technically, functions are just objects that can be called. But it still strikes me as kinda crazy.
Good stuff here.
var that = this;Number automatically accepts exponent notation and auto-converts to hex (ignoring octal). parseInt() auto-converts hex and octal unless a radix is specified, but it also ignores the remaining non-number characters at the end of the string.
There isn't a single method that does whatever you want.
An other thing that could maybe be covered is this specifity:
typeof "42" === "string"
typeof String(42) === "string"
typeof new String(42) === "object"
'42' | 0; // 42
NaN | 0; // 0
null | 0; // 0
undefined | 0; // 0
false | 0; // 0
true | 0; // 1The behavior of Number, Boolean, String, and Array is well-defined, it's safe to call them without new. In fact, in the case of String/Boolean/Number, calling them with new will often do something you don't expect. (Calling them with new gives you a Number/String/Boolean object, not primitive, which can cause trouble when you try to compare them with ===, unless you remember to use their `valueOf` method)
Also, as noted below, it's possible for objects to not have a `toString` method, so attempting to call it to get the object's value as a string could blow up. So it's actually safer to coerce to string by adding an empty string or passing to String().
Approximate Range -> (-7.9 x 1028 to 7.9 x 1028) / (100 to 28)
Precision -> 28-29 significant digits
Well, except for right logical shifts.
On the server-side async/await are worth their weight in gold... and using lambdas is very nice. I still don't like the ES6 module syntax over node/commonjs require statements though.
The only thing to be really mindful of is when you browserify for the client that you don't accidentally include, for example the entire crypto library, buffer or similar shims because they can get very big, very quickly.
>>> foo.test
<unbound method foo.test>
>>> x.test
<bound method foo.test of <__main__.foo instance at 0xf74d68ac>>
>>> z = x.test
>>> z(123)
<__main__.foo instance at 0xf74d68ac> 123
z = x.test.bind(x)
// z is: function () { [native code] }
z(123)
// foo {test: function} 123Note that the behaviour of `this` defaulting to `window` (or `global`) is only the legacy behaviour. You should be using strict mode (there's really no justification not to -- except for extremely rare edge cases, e.g. having to delete global variables without having a reliable reference to the global object other than `this`).
In strict mode, `this` would be undefined. As expected, if you consider `x.y()` syntactic sugar for `x.y.call(x)` (and therefore `z()` syntactic sugar for `z.call(undefined)`).
Under the hood, invoking a function translates to a call of the functions `[[Call]]` method, which takes an explicit `this` just like `Function.prototype.call` does.
var foo = {
doSomething:(...argv)=doSomethingMethod(foo, argv)
};
return foo;
It's similar to what Crockford now presents as a preferred approach in dealing with having context for functions... I just like discrete functions that can be tested independently of their execution context... by passing the context as a parameter, this becomes explicit... with binding, the process becomes transparent.
Caching the array length still gives you a small speed boost in most browsers, but it's probably an over optimisation unless you're doing something really intensive.
If you're just writing ordinary business code (i.e. in 80% of all code out there), by all means, please use forEach and friends.
Besides, if you're doing number crunching in JS, you probably want to stick to ASM.js anyway.
ES6 is packed with weird but well-defined things.
The problem is that calling a constructor function (a PascalCase'd function) without `new` looks like an error because it generally is an error. To make matters worse, without closely examining that function, you cannot tell if it's an error.
I do know that `Number()` happens to be one of those constructor functions which not only work without `new`, it also happens to behave differently when `new` is missing. It does not return an object. It returns a primitive.
Someone who doesn't know about this unusual secondary function will waste some time if they spot this apparent mistake.
Now, to defuse this time-wasting trap, you could either add a comment... or just do the sensible thing and write it in a way which does not require a comment.
Python throws an error, but numpy.divide(1., 0) will work just fine (and return inf).
I'm not sure why you're saying C throws an error. The behavior of dividing by 0 is undefined by default, but on most machines these days the hardware implements IEE-754 and the C implementation will advertise as implementing IEC 60559, so 1. / 0 will give you inf as well.
How can you create an object which can be called like a function, but will respond to 'typeof' with 'object' rather than 'function'?
What happens when you try to call an object - what's the error? Try it, in a few of your favourite javascript interpreters:
({})()
You can't, by definition. Here is the relevant section of the ECMAScript 5 spec: http://www.ecma-international.org/ecma-262/5.1/#sec-11.4.3
Basically, an object which implements call will always cause `typeof` to return "function". But the broader point is that `typeof` will lie to you and you shouldn't trust it for, you know, determining the types of values. (For example, the type of null is null, but `typeof null` returns "object".)
As I noted above, this behavior of `typeof` is part of what causes the confusion around types in JS devs.
> You can't substitute an object where a function is expected - you get a type error - but you can substitute a function where an object is expected.
This is true, but not inconsistent with the notion that functions are objects which can be called. I encourage you to read the spec I linked above, or a draft of ES6.
In short, I think the spec is incorrect in its use of the concept of types; or incomplete.
You'll note that the spec uses the concept of "internal properties" to distinguish between the different things one can do with values. From a type theory perspective, these internal properties and the implied permitted operations come close to type definitions. It's a matter of perspective, then, when one is using the word 'type' as defined by a particular language's spec, or 'type' as in programming language pragmatics / type theory POV. For the generalist programmer who knows more than one language, a broader concept of types is usually more useful.
Further, the spec uses these internal properties solely to define the semantics of the language, and they are not necessarily visible artifacts of any implementation. Talking about them as if they were concrete confuses the map with the territory.
Are there any implementations which actually do this? In Node:
typeof({ call: function () { } }) --> 'object'
({ call: function () { } })() --> TypeError: object is not a function
Though, I don't use delete much, I honestly don't worry about it much. In most contexts it's a bit of a premature optimization unless you are in a very low-level tool that will be used for example gaming, video or photo manipulation, there are probably better optimizations to make.
var controller = this;
Why do you think they decided to do this? Strict mode is to allow folks to transition their code to the new standard - and the new standard has made this decision to fix a flaw in JavaScript - it acknowledges its a hack to return the global object in this case.
So I'm less editorialising and more pointing out what is already known. Hope this helps.
It's why ES5 has bind to get around this.
Example from MDN [1]
this.x = 9;
var module = {
x: 81,
getX: function() { return this.x; }
};
module.getX(); // 81
var getX = module.getX;
getX(); // 9, because in this case, "this" refers to the global object
// Create a new function with 'this' bound to module
var boundGetX = getX.bind(module);
boundGetX(); // 81
var module = {
x: 81,
that: this,
getX: function() { return that.x; }
};
1. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...