New Syntax

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Douglas Crockford: So saying that we couldn't resist adding some new syntax. We did it not too much and I'll warn you all of these are fatal errors in browsers before IE 9, so if you're still on IE 8 please ignore the following. So we added trailing commas to object literals, which is not useful, I don't recommend you use it.

[00:00:30]
The reason we did that was because we fixed the way trailing commas worked in array literals. It turns out arrays always allowed that dangling comma but they disagreed on what it meant. On some browsers that array would have a length of two. On IE browsers it had a length of three.

[00:00:48]
When you have that kind of disparity bugs can happen so we changed it so the rule is now the dangling comma is ignored so everybody will agree that it has a length of two. We fixed a terrible reserved word policy. JavaScript's original reserved word policy said that you could not have a reserved word in name position, in an object literal or in dot position and there's is no reason for that.

[00:01:18]
We fixed that. So everything that's yellow now used to be an error, that's all now okay. So that's good. In fact the reason that JSON requires quotes around its names was because of this design problem in ES3. We added getters and setters. These are accessor properties, so that when you go to retrieve a value from an object or go to store a value into an object, instead a function will be called which will either consume your value or return a value.

[00:01:55]
And that allows some new forms of programming. So here we've got a temperature constructor which has a celsius property and a fahrenheit property. You can read either one and you can set either one. You don't know how it works but it just works. That's a pretty nifty thing.

[00:02:14]
Now turns out you can do some really stupid stuff with this because if you use this correctly, then these methods will be very limited, very restricted in what they do, but there is no actual restriction on them. They can do anything. They can change everything in the world and so you can simply by reading a property of an object you can cause things to happen over there.

[00:02:39]
I don't recommend you do that because it's stupid. I'm sure somebody is gonna do that and they're gonna, I bet nobody thought that you could do that, and will go and do that. We actually did think about that, just hoping nobody does that. Earlier, we talked about the multiline string literals, I still think this was a mistake.

[00:03:00]
>> Douglas Crockford: This is great. So it used to be infinity, NaN and undefined were not constants, they were global variables, which meant you could change them. You could say today infinity is five, let's see what happens.
>> [LAUGH]
>> Douglas Crockford: I know that security experts were very worried about someone redefining undefined, and what the consequences of that could be.

[00:03:24]
I'm not aware of any exploits that actually happened as a result of that, but it is something that was worried about. So they are now read only variables. So [SOUND] now that's fixed. We fixed parseInt so that it no longer defaults to octal when the first character is zero.

[00:03:41]
I still recommend putting in the radix argument anyway but at least the least the default behavior is not nearly as bad as it had been. Regular expression literals now will produce a new regular expression object every time they're evaluated, so they work the same way that functions do.

[00:03:58]
The reason we did that, originally the compiler would only create one regular expression object for each regular expression literal. And the problem with that is, that they contain state. For example they contain a last, what was it last position or last, anybody remember? The thing that exec uses to remember where the last match happened.

[00:04:21]
No one knows? Anyway, there's this variable that's in there which if everybody is sharing it, then you can't have multiple execs happening because they'll interfere with each other so we fixed that. This was awful, so I told you earlier about the object function. It gets called every time you make an object, and the array function gets called every time you make an array.

[00:04:47]
It turns out you could replace those functions with your function so you get called every time someone makes an object or an array. And that's a huge security violation, right? You don't want some code to be able to take those things over, so the specification will now say as if by the original object function or array function that you can still replace them but you don't get the security hazard.

[00:05:13]
I'm happy to report that JSON, the world's best loved data interchange format, is now built into the language. So we've got a JSON object that provides a parse function and a stringify function. Those names are my fault, completely my fault. I probably should have said encode or decode, or something like that, but I didn't.

[00:05:32]
So we're stuck with those, so, you're welcome.
>> [LAUGH]
>> Douglas Crockford: If you're using json2.js then it works exactly the same, except json2.js knows to get out of the way if built in one is there, so it'll just get faster which is what you want.