Getting the comments with a getter seems fine. Appending only the list of comments with a setter is bad, as it does not resemble storage semantics. I would expect well written setters to at least be idempotent, and well written getters to be side effect free.
On Tue, Oct 16, 2012 at 2:36 PM, Tab Atkins Jr. <[email protected]>wrote: > On Tue, Oct 16, 2012 at 2:24 PM, Allen Wirfs-Brock > <[email protected]> wrote: > > On Oct 16, 2012, at 1:25 PM, Yehuda Katz wrote: > >> Agreed. For example: > >> > >> class Post { > >> > >> } > >> > >> class Comment { > >> > >> } > >> > >> Post.hasMany("comments"); > >> Comment.belongsTo("post"); > >> > >> let post = new Post() > >> let comment = new Comment(); > >> > >> comment.post = post; > >> post.comments //=> [comment] > > > > A great example of where you should not use an accessor. As a rough > > guideline accessors (which are syntactically models after state > attributes) > > should be used to set/query local characteristics of objects. Methods > > should be use for complex computations and for establishing and accessing > > complex relationships among objects. Why? Because experience with > complex > > object models have shown that you have more > > understandable/extensible/maintainable systems when you are careful about > > where and how you expose coupling among objects. > > > > In this case, there is a bi-directional n-to-one relationship being > > maintained between objects. Such complex relationships are best modeled > > using methods because their require establishing and maintaining the > > relationship requires state changes in multiple objects. Expressing the > > operation as a method serves as a warning that something more complex > than > > simply updating some local state is going on. > > > > > >> This is similar to certain DOM APIs, and my expectation of a > hypothetical > >> version of Ember Data in ES6 would work. I don't think there is anything > >> wrong with using an accessor here. > > > > I don't think anybody hold the DOM up as a stelar example of > Object-oriented > > design. > > > > You might not agree with the above guideline, or choose to follow it. > > That's fine. But, what you you propose as an alternative. What are your > > guidelines for choosing to use an accessor rather than a method? If you > > consider you example to be a reflection of "good design" what are the > > specific design principles it is following. Why is that an appropriate > > place to use an accessor. > > I consider Yehuda's example to be a perfectly fine and completely > normal place to use an accessor. *Accessing* the list of comments > attached to a post is conceptually a side-effect-free operation. > While it can change over time, it only does so due to obvious actions > - querying it twice, one immediately after the other, *will* give === > results. > > *Setting* the attribute may have side-effects, but reasonable ones > (setting/unsetting Comments.post or Post.comments on other objects). > This is a reasonable thing for a setter to do. > > I don't see any reason to make these two into methods. > > ~TJ > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
