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

Yehuda Katz wycats at
Wed Oct 17 08:32:25 PDT 2012

On Wed, Oct 17, 2012 at 11:16 AM, Mark S. Miller <erights at> wrote:

> On Tue, Oct 16, 2012 at 4:06 PM, Yehuda Katz <wycats at> wrote:
>> On Tue, Oct 16, 2012 at 6:26 PM, Mark S. Miller <erights at>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?
> Yes.
>> ` = post` has similar semantics to setting a foreign key in a
>> SQL database, which will (obviously) update future requests for "all
>> comments with". 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.
>> = post is, of course idempotent. Setting it to the same
>> value as it already has would have no effect.
> Good. In light of this, I reread the original post of your example. I had
> misunderstood it.
> I strongly agree with those earlier posts saying that we should have some
> well thought out design guidelines for when to use an accessor vs a method,
> and that accessor usage should only be "storage-like". However, now that I
> understand it, I also agree that your example is storage-like enough to my
> eyes that I would like guidelines that permit it as a normal case. I do not
> yet a concrete suggestion other than "getters should be query-only" and
> "setters should be idempotent and not cause 'external' effects (other than
> notifying registered observers)." The key thing about your example is "What
> does external mean?" I don't yet have an answer to offer.
> These guidelines are not prescriptive on any external JS community. But we
> need guidelines for APIs designed by TC39 and (hopefully eventually) by w3c.

The reason for my examples was just to illustrate that if ES.future had an
API similar to what I presented, I would want it to be an accessor. As a
result, I disagreed with the original proposed guideline.

I like the idempotent requirement, but I'm not sure I agree with the
observer distinction. Especially if the observer is behind the abstraction
boundary, but has observable external side effects (exactly what is
happening in my example), it seems indistinguishable from doing the work in
an accessor.

> --
>     Cheers,
>     --MarkM

Yehuda Katz
(ph) 718.877.1325
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list