On Wed, Oct 17, 2012 at 11:16 AM, Mark S. Miller <erig...@google.com> wrote:
> On Tue, Oct 16, 2012 at 4:06 PM, Yehuda Katz <wyc...@gmail.com> wrote: > >> On Tue, Oct 16, 2012 at 6:26 PM, Mark S. Miller <erig...@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? >> > > Yes. > > > >> >> `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. >> > > 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
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
