It was presented at ACSAC 2012.
Symbols are sort of JavaScript's answer to private members. Closest to __ for members in Python.
I'm more concerned about adding features without fully considering the consequences. When you add a feature to Javascript, it's there forever. Rushed feature dumps are how we end up with things like the Web Audio API.
And the compilation is pretty light. The syntax is different, but for the most part the semantics are 1:1 with Javascript.
Having said that, any compile-to-language is going to introduce problems that need to be solved. Source maps and short watch+compile times have basically eliminated any problems for me.
Have a single polymorphic function called type: type() gets the type, type(value) sets the type.
Have .get and .set functions, called like: get('type'), set('type', value).
var obj = new Proxy(
{foo_: "bar"},
{get: function(target, name) {
return target[name + "_"];
});
console.log(obj.foo); //logs "bar"
What I'm really excited about is reactivity on objects for setting and getting without using functions. You could have your setter trigger events without forcing someone to use a set function like you have in Backbone.
I think we'll see an entirely new set of model libraries because of these new ECMAScript 5 and 6 features.
Does anyone have an estimate for when ECMAScript 6 will be widely deployed across browsers, almost ubiquitous? I would say now it's safe to use SVG in many situations on the web that would not have been OK a few years ago, I'm curious about when the tipping point will be with ECMAScript 6.
Anecdotally, recently my customers have been a lot less interested in supporting older versions of IE, and I have used SVG in a couple of situations, and that would not have been OK a few years back. I have not been closely following the developments of ECMAScript 6, it has seemed like it will be a while until it's widely deployed. The only things I have found practical use for are typed arrays, and I have been using them in node specific code rather than in code that I expect to run across browsers.
Though I am interested in the latest developments in JavaScript, my focus will still be on what can be done with the JavaScript available in almost every browser. I am also interested in making use of getters and setters in my code but being able to compile it to ECMAScript 3, I may be able to do some relatively simple text replacement rather than having to parse and compile an abstract syntax tree.
Doable with "old" JS. Consider this function:
function prop(name, gNs) {
var _name = '_' + name,
get = gNs && gNs.get,
set = gNs && gNs.set,
undef = function (v) { return typeof v == 'undefined'; },
if (get && set)
return function (x) { return undef(x) ? get.call(this, this[_name]) : (this[_name] = set.call(this, x), this); }
if (get && !set)
return function (x) { return undef(x) ? get.call(this, this[_name]) : (this[_name] = x, this); }
if (!get && set)
return function (x) { return undef(x) ? this[_name] : (this[_name] = set.call(this, x), this); }
return function (x) { return undef(x) ? this[_name] : (this[_name] = x, this); }
}
1: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Thanks for the update.
Edit, tested and updated blog post. Thanks again.
Careful. These have different behavior for own properties which are not enumerable. A for-in loop doesn't include them, but Object.getOwnPropertyNames does.
1) JavaScript is starting to become a "big" language, in terms of number of keywords and syntax;
2) While many of these things that JavaScript is (finally) gaining are things we're familiar with in other languages (and have empirically found to be useful), they often seem somewhat more unwieldy, fiddly, and complicated in JavaScript.
As a handwavy example, Ruby generally has most of the stuff these sorts of articles describe, and it can be complicated at times, but usually (in my experience) only when you're trying to do something complicated anyway; in JavaScript, a lot of it looks quite complicated out of the box even when you're doing something that ought to be simple.
There are many JavaScript developers out there, some with years of experience, who are confused about, say, `var Foo = function() {}` versus `function Foo() {}`, or the difference between `new Foo()` and `Object.create(Foo.prototype)`. To be honest, it slightly worries me that even more complexity is being added at this point.
var foo = {};
Object.defineProperty(foo, 'bar', { value: 'baz' });
foo.defineProperty('bar', { value: 'baz' }); foo.foo = "bar";
Object.defineProperty(foo, 'bar', { value: 'baz' });
Regarding your second question, defineProperty is a method on Object, not Object.prototype. "Instances" as you might call them only have direct access to methods found on their prototype chain. You can think of Object.defineProperty as a static method on Object if that helps. I wrote a post about "this" which includes some information about prototypes:
http://bjorn.tipling.com/all-this
You should probably first checkout the mdn documentation though: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...