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

Mark S. Miller erights at google.com
Tue Oct 16 15:26:12 PDT 2012


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. <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121016/3c5e29c5/attachment.html>


More information about the es-discuss mailing list