4 ms·

This is the only intelligent comparison I have seen of Ember & Angular (or actually of Angular with any other modern framework). Thanks! I am wondering if the

This is the only intelligent comparison I have seen of Ember & Angular (or actually of Angular with any other modern framework). Thanks! I am wondering if the uniform access principle is mostly a dynamic language issue: you end up screwing up whether you need a parentheses invocation and you don't know until runtime. If you type everything with TypeScript then you know at compile time if you messed it up. Relatedly, Ember's get/set is more difficult to make strongly typed. In the TypeScript definitions I am looking at, property access is only typed as a string. One could define an enum for each object to be used in place of the string, but overall there is a price to pay with set/get since it isn't baked into the language (like Ruby).

emn13 13y ago
I think the uniform access principle is misguided (or at least misconstrued). It's a bad idea... in general. If you're building an API and you have need some kind of stable, unchanging interface to expose - then it makes sense. But people are using it everywhere in their programs; and it's not really valid there. First of all, data-access is fast and computed functions may be slow. Hiding this difference means that writing efficient code becomes more tiresome - you need to consider each and every access as potentially expensive, even though the majority are probably trivial. This means you need to know the code better to get anywhere. And if you make it hard to write efficient code, people won't bother (and rightly so, since that's usually premature optimization). Secondly, in most languages, simple data access is side-effect free and (usually) thread-safe or at least has predictable threading behavior. Managing side-effects - even without threading - is a major pain in any large code base, and although functional purity can be enforced otherwise in some languages, in most cases you've got nothing to go on. Making your life more difficult by discarding annotations that distinguish between method calls and member access isn't helping. Of course, in a dynamic languages you're in a tricky spot here - it's hard to refactor, so exposing member access is something that's more work to change later when you discover you need computation or a side effect. However, even so; making a system harder to reason about for the purpose of a fairly pointless architectural purity is usually a bad idea. The uniform access principle as applied to interfaces is another story; but in general use - I think it sounds nice in theory, but works poorly in practice.
- dragonwriter 13y ago
  > The uniform access principle as applied to interfaces is another story The uniform access principle is a principle of interfaces, it doesn't apply to anything else.
  - emn13 13y ago
    That's kind of exactly my point :-). It rarely has a place in the internals of your webapp, and as such makes no sense as a design philosophy for object patterns aiming to be used largely in the internals of your webapp.
- machty 13y ago
  Keep in mind that Computed Properties are also part of the solution to intelligent, efficient data-binding. CPs in Ember are cached and quite efficient and because they are aware of their dependencies, much of the computation that would otherwise need to go into a dirty-checking approach to data-binding can be avoided. So, Uniform Access is part of it, but I would advise against scrapping an initial implementation of your app using CPs on performance grounds considering that data-binding is the main performance bottleneck in Ember (and Angular).
- pcwalton 13y ago
  JavaScript hasn't had simple data access for a long time if ever. Computed properties have been widely supported for a long time, there's "watch" [1], and of course there's the prototype chain. ES6 adds proxies, which makes practically everything you might want to do with an object potentially have custom behavior. IMHO, in JavaScript you might as well respect the uniform access principle, since "a.b" meaning simple data access has arguably never existed. [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/watch https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - emn13 13y ago
    Since code could be self-modifying; clearly simple-data access has never been a guarrantee. But in practice, today as ever, it's a good guideline. When you see an accessor, it will almost always be fast and side-effect free. Now, part of that is because not all browsers support the features you refer to and therefor these features just don't get used much. But even in languages like C# and python, that have had real accessors for a long time, it's still a good guideline: it's generally considered bad practice to make a slow, side-effectful accessor, and most people don't. Controlling side effects and performance are important, and the uniform access principle has little upside in most non-public code, yet considerable cost in that it obscures one of the few indicators mainstream languages have for these aspects.
ryanto 13y ago
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.
- peferron 13y ago
  Wouldn't getters solve this better?
  - machty 13y ago
    getters + defining `first` and `last` as Computed Properties would solve this problem
    - aidos 13y ago
      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 13y ago
        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 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/ http://emberscript.com/)
dragonwriter 13y ago
> I am wondering if the uniform access principle is mostly a dynamic language issue: you end up screwing up whether you need a parentheses invocation and you don't know until runtime. The uniform access principle is mostly about enabling refactoring and information hiding -- consumers of your code shouldn't care whether an attribute is the result of direct member access or method invocation, and if you change from one to the other, it shouldn't break client code.

emn13 13y ago

I think the uniform access principle is misguided (or at least misconstrued). It's a bad idea... in general. If you're building an API and you have need some kind of stable, unchanging interface to expose - then it makes sense. But people are using it everywhere in their programs; and it's not really valid there. First of all, data-access is fast and computed functions may be slow. Hiding this difference means that writing efficient code becomes more tiresome - you need to consider each and every access as potentially expensive, even though the majority are probably trivial. This means you need to know the code better to get anywhere. And if you make it hard to write efficient code, people won't bother (and rightly so, since that's usually premature optimization). Secondly, in most languages, simple data access is side-effect free and (usually) thread-safe or at least has predictable threading behavior. Managing side-effects - even without threading - is a major pain in any large code base, and although functional purity can be enforced otherwise in some languages, in most cases you've got nothing to go on. Making your life more difficult by discarding annotations that distinguish between method calls and member access isn't helping. Of course, in a dynamic languages you're in a tricky spot here - it's hard to refactor, so exposing member access is something that's more work to change later when you discover you need computation or a side effect. However, even so; making a system harder to reason about for the purpose of a fairly pointless architectural purity is usually a bad idea. The uniform access principle as applied to interfaces is another story; but in general use - I think it sounds nice in theory, but works poorly in practice.

dragonwriter 13y ago
> The uniform access principle as applied to interfaces is another story The uniform access principle is a principle of interfaces, it doesn't apply to anything else.
- emn13 13y ago
  That's kind of exactly my point :-). It rarely has a place in the internals of your webapp, and as such makes no sense as a design philosophy for object patterns aiming to be used largely in the internals of your webapp.
machty 13y ago
Keep in mind that Computed Properties are also part of the solution to intelligent, efficient data-binding. CPs in Ember are cached and quite efficient and because they are aware of their dependencies, much of the computation that would otherwise need to go into a dirty-checking approach to data-binding can be avoided. So, Uniform Access is part of it, but I would advise against scrapping an initial implementation of your app using CPs on performance grounds considering that data-binding is the main performance bottleneck in Ember (and Angular).
pcwalton 13y ago
JavaScript hasn't had simple data access for a long time if ever. Computed properties have been widely supported for a long time, there's "watch" [1], and of course there's the prototype chain. ES6 adds proxies, which makes practically everything you might want to do with an object potentially have custom behavior. IMHO, in JavaScript you might as well respect the uniform access principle, since "a.b" meaning simple data access has arguably never existed. [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/watch https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- emn13 13y ago
  Since code could be self-modifying; clearly simple-data access has never been a guarrantee. But in practice, today as ever, it's a good guideline. When you see an accessor, it will almost always be fast and side-effect free. Now, part of that is because not all browsers support the features you refer to and therefor these features just don't get used much. But even in languages like C# and python, that have had real accessors for a long time, it's still a good guideline: it's generally considered bad practice to make a slow, side-effectful accessor, and most people don't. Controlling side effects and performance are important, and the uniform access principle has little upside in most non-public code, yet considerable cost in that it obscures one of the few indicators mainstream languages have for these aspects.

ryanto 13y ago

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.

peferron 13y ago
Wouldn't getters solve this better?
- machty 13y ago
  getters + defining `first` and `last` as Computed Properties would solve this problem
  - aidos 13y ago
    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 13y ago
      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 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/ http://emberscript.com/)

dragonwriter 13y ago

> I am wondering if the uniform access principle is mostly a dynamic language issue: you end up screwing up whether you need a parentheses invocation and you don't know until runtime. The uniform access principle is mostly about enabling refactoring and information hiding -- consumers of your code shouldn't care whether an attribute is the result of direct member access or method invocation, and if you change from one to the other, it shouldn't break client code.