Hacker News Reader

Comment by jvickers | Hacker News Reader

Alternatives to getType and setType functions (while still not using getters and setters):

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).

I like that idea, but with Proxy you don't have to write the functions any more, you could just define that one get on the handler you feed into Proxy and then in your code you can access via the . notation, like:

  var obj = new Proxy(
   {foo_: "bar"}, 
   {get: function(target, name) {
     return target[name + "_"]; 
   });
  console.log(obj.foo); //logs "bar"

Of course maybe you'd do something a little fancier than just return the value, like return null for property names with _ to prevent accessing private variables. I don't know what the performance of Proxy will be like, but it's an alternative to getters and setters and lets you have a fall through for things you haven't defined.

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.

I'm not yet excited about these getters and setters and new features in the latest JavaScript. I've put a lot of time and effort into developing ECMAScript (JavaScript) 3 patterns that overcome various limitations, and have got accustomed to the idea of deploying ECMAScript 3. In terms of providing an API, getters and setters will be very useful. It will be good to have out-of-the-box JavaScript functionality that does not require extra code to use, like various methods I use to overcome the ECMAScript 3 limitations.

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.

https://github.com/google/traceur-compiler/wiki/GettingStart...

Kangax's ES6 Compatibility Table tracks the implementation status for many browsers, though Chrome's ES6 support is hidden behind a pref: chrome://flags/#enable-javascript-harmony

http://kangax.github.io/compat-table/es6

> with Proxy you don't have to write the functions any more, you could just define that one get on the handler you feed into Proxy

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); }
    }

Pass `prop` (a) the name of a property you're defining getter/setter methods for and (b) an object with any custom getter/setter you might care to define (or neither, if you like), and it'll return a function that will act as both which you can assign to a prototype.

I like that, but you'd still have to call a function to get the properties though and this wouldn't prevent anyone from accessing those properties directly.

Like:

  obj.setFoo("bar");
  obj.getFoo();
  obj.foo = "bad stuff"; //overwritten

instead of

  obj.foo = "bar";
  obj.foo;
  obj.foo_ //error, not allowed access

True enough, and if privacy is a must have, my implementation is a non-starter.

I tend towards the (somewhat unpopular and certain arguable) opinion that need for privacy via a runtime-enforced mechanism is overrated... give us developers using an API/library effective/well-documented methods that do what we need and warn us when we shouldn't touch something with a convention (like an underscore), and usually we're happy to leave the black box closed.

It's usually when abstractions leak or implementations aren't complete that we're tempted to tinker across boundaries, and when that happens, the lack of a privacy enforcement mechanism may not be the real problem.

(OTOH, they can indeed help keep some bad situations from getting worse, and when trusted code is mingling with untrusted in situations like web mashups, privacy-enforcement can be really helpful for security...)

I don't know why, because I haven't thought through it enough yet but I really like the idea of freezing or protection in the case of a reactive data model like Backbone models. I'm thinking of maybe writing up some quick implementation where you provide a schema and you get a reactive object that is frozen and has a catch all. Just want to see where that goes.

Reply on news.ycombinator.com