On Tue, Oct 16, 2012 at 6:26 PM, Mark S. Miller <[email protected]> wrote:
> 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. Do you mean appending only *to* to list of comments? `comment.post = post` has similar semantics to setting a foreign key in a SQL database, which will (obviously) update future requests for "all comments with post_id=post.id". Bidirectionally linked one-to-many relationships are pretty common, and it's desirable for the relationships to remain in sync automatically. I don't think this is the right heuristic for moving to a method. I would expect well written setters to at least be idempotent, and well > written getters to be side effect free. comment.post = post is, of course idempotent. Setting it to the same value as it already has would have no effect. > > 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 > > Yehuda Katz (ph) 718.877.1325
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
