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