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

Yehuda Katz wycats at gmail.com
Tue Oct 16 14:55:35 PDT 2012


Yehuda Katz
(ph) 718.877.1325


On Tue, Oct 16, 2012 at 5:43 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

>
> On Oct 16, 2012, at 2:36 PM, Tab Atkins Jr. wrote:
>
> > On Tue, Oct 16, 2012 at 2:24 PM, Allen Wirfs-Brock
> >>
> >> 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.
>
> So, what are the design guidelines that you would apply leads to these
> being accessors?   When do you use a method?  When do you use an accessor?
>

One possible approach would be to have clear design guidelines for
*getters*, and allow setters with reasonable observable side-effects for
getters that comply. That is the approach I use in my designs.


>
> Allen
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121016/a9ff5dcf/attachment-0001.html>


More information about the es-discuss mailing list