ES accessor usage guidelines (Was: Map/Set.prototype.size)

Yehuda Katz wycats at gmail.com
Tue Oct 16 16:06:54 PDT 2012


On Tue, Oct 16, 2012 at 6:26 PM, Mark S. Miller <erights at google.com> 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. <jackalmage at gmail.com>wrote:
>
>> On Tue, Oct 16, 2012 at 2:24 PM, Allen Wirfs-Brock
>> <allen at wirfs-brock.com> 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
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> --
>     Cheers,
>     --MarkM
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>

Yehuda Katz
(ph) 718.877.1325
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121016/538e8686/attachment.html>


More information about the es-discuss mailing list