Re: Making properties of a class unenumerable

On May 29, 2014, at 11:01 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Thu, May 29, 2014 at 10:06 AM, Allen Wirfs-Brock
> <allen@wirfs-brock.com> wrote:
>> Yes, this was a conscious design decision by TC39.  See
>> https://github.com/rwaldron/tc39-notes/blob/master/es6/2012-09/sept-18.md#concise-method-definition-revisited
>> and a change from what was original proposed.  TC39 consensus was driven by
>> the belief that JS developers expect everything they define to be
>> enumerable.
> 
> That makes sense. However, is it problematic if "platform objects" do
> not always follow this pattern? Boris and I are basically unsure
> whether the restriction is meant to apply to everything defined
> outside of TC39.
> 
> (Note that there are some implications here for
> https://gist.github.com/annevk/6bfa782752dde6acb379 as then these
> objects would not behave like built-ins, but still be built-ins.)

Even though ES6 class definitions default methods to enumerable, we’ve chosen to make new ES6 built-in methods non-enumerable.  We did this for consistency with the built-in methods defined by prior ES editions. The web platform might consider following along with that same logic, although it is certainly possible to define built-in methods that are enumerable and for ES code to force class defined method to be non-enumerable.

One of the reasons TC39 wasn’t overly concerned about inconsistency among the enumerability of methods is that it primarily only impacts for-in iteration.  We expect the use of for-in (and hence the significance of the enumerable attribute) to fade away with the introduction of for-of.  If you are defining new platform where it makes sense to do some sort of iteration over some of the object’s properties then it probably makes sense to define an @@interator method rather than assume that use of for-in and enumerable properties.

Allen

Received on Thursday, 29 May 2014 13:59:21 UTC