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

Tab Atkins Jr. jackalmage at
Tue Oct 16 14:54:30 PDT 2012

On Tue, Oct 16, 2012 at 2:43 PM, Allen Wirfs-Brock
<allen at> 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 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?

As getters, I think it's self-explanatory.  They're idempotent and effect-free.

As setters, they do go beyond what Brendan suggested in his original
formulation, but the effects still feel reasonably "local" to me.
Whether the setter is considered to have non-local effects or not is
actually just a question of implementation, not essence - we could
implement the setter simply and naively, and have the getters do an
expensive tree traversal to assemble the answer, or have the getter be
simple and naive, and have the setter reach in and do some mutations
to maintain the state of the tree.


More information about the es-discuss mailing list