[ryanto]

Uniform access principle is nice to have in JavaScript, a dynamic language like you pointed you. One of the nice things is it makes refactoring a bit easier. Imagine you have code that reads:

  person = {
    name: "ryan to",
    first: function() {
      return this.name.split(/\s/)[0];
    },
    last: function() {
      return this.name.split(/\s/)[1];
    }
  }

But you realize this could be harmful, so you want to change it to:

  person = {
    name: function() {
      return this.first + " " + this.last;
    },
    first: "ryan",
    last: "to"
  }

All of a sudden your code breaks because person.name needs to become person.name(), person.first() to person.first, etc. That is somewhat hard to track down/refactor in a large JavaScript code base, or any dynamic language code base for that matter.

Uniform access principle is, in my opinion, one of the selling points for implementing your own object model in JS.

[Renaud]

Wouldn't TypeScript help a lot in handling these changes?

You break/change something and then the rest of your code wouldn't compile until you fixed it everywhere (and it would show you where). You wouldn't have to worry whether you forgot something since the compiler wouldn't let you get away with it. Refactoring tools on top of TypeScript (like Resharper and Coderush) will eventually be able to safely do these changes quickly across the whole project.

[epidemian]

But it's cumbersome to have to change lots of code just because a property of some object became computed instead of directly stored (or vice versa). And it's unfeasible to do so if you're developing a library (for external usage, or internal usage within a company)... you can't just go and fix all the code that used it.

[peferron]

Wouldn't getters solve this better?

[machty]

getters + defining `first` and `last` as Computed Properties would solve this problem

[aidos]

Computed properties are a good workaround. Getters and setters could be better though. That way no one on the outside of the object needs to know the details at all. Am I right in saying that by sacking off old IE browsers we could switch to getters and setters (as in, native js implementation) already?

[nixme]

Almost.... and Ember can mostly work with that last time I checked.

The missing piece is delegation though, i.e. you can't define a catch-all getter/setter and many Ember.*Proxy classes/mixins (e.g. http://emberjs.com/api/classes/Ember.ObjectProxy.html) rely on that. Like most Ember Controllers are delegating data state to a model, and are supplementing app state/behaviors on top.

ES6 Object Proxies fixes that.

But I'm liking how fast the Ember team has been including ES6 transpilers into directly in to Ember App Kit. So we may be writing more regular JSy looking property dot notation, like Angular, soon enough. And get all the benefits of UAP.

(By the way, for coffeescript fans, ember-script sort of does this for you: http://emberscript.com/)

[taude]

Great example here. I've been running into this same idea a lot in Knockout.JS lately.