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

Brendan Eich brendan at
Mon Oct 15 09:23:18 PDT 2012

Allen Wirfs-Brock wrote:
> On Oct 12, 2012, at 2:16 PM, David Herman wrote:
>> On Oct 12, 2012, at 12:14 PM, Erik Arvidsson<erik.arvidsson at>  wrote:
>>> On Fri, Oct 12, 2012 at 11:16 AM, David Bruant<bruant.d at>  wrote:
>>>> Firefox has implement a Map/Set.prototype.size *method* to query the number
>>>> of mapping/elements.
>>>> It's not in the strawman. It appears in the latest draft, though weirdly
>>>> enough Map.prototype.size is a function with an unused argument.
>>>> What about making it an getter instead of a function? I guess we also don't
>>>> need the extra parens to request for Map#keys, Map#values, Map#items.
>>> For keys, values and items I think they are cleaner as methods since
>>> they return a new iterator every time.
>> Agreed.
>> Dave
> I buy making Map/Set size an accessor.  This will be the first such property in the ES specification and it would be good to have some guidelines to help us make consistent decisions about using accessors in the future.
> Erik and Tab floated a couple reasons why items/keys/values should not be accessors.
> Does anybody want to  take a crack at writing up a complete set of design rules for when a built-in property should/shouldn't be defined as an accessor?

Simpler is better. Tab, Arv, and others hit the big one. Here's a first cut:

* get-only accessor for non-writable property must be idempotent, 

* get/set accessor may have effects on 'set' (see the DOM) but only on 
the receiver object (and unobservably, any children that become garbage, 
e.g. when trimming .length on an array-like).

* get/set accessors should reflect as such. This means Array.length gets 
a legacy dispensation, and __proto__ needs poisoning.

* anything else is a method.


More information about the es-discuss mailing list