classes and enumerability

Andrea Giammarchi andrea.giammarchi at
Wed Dec 24 17:36:59 PST 2014

I'm sure there are cases, that's why I've written a possible solution that
is quite straight forward for those cases, but I am still curious to see a
concerete example. In other PL, when you serialize in order to deserialize
in a 1:1 way, you never have getters/setters in, just the properties that
will make again those getters/setters meaningful.

However, to just pass data around, I see if that accessor contains a
sensible info, of course you want it in.

I wonder if this is really the most common case though ... and if we should
make the enumerability desired as such most common case.

We could have the ability to chose instead and use old patterns when
needed, through all object literals improvements and over prototype
assignment ... but, can we have something better and more suitable for
classes wiith the new ES6 class sugar?

Going "all enumerable" is not future friendly, rather past friendly, and
the whole idea of is to have the past still compatible within new
Why carrying old gotchas in is not a good way to clean-up or go toward
better patterns.


On Thu, Dec 25, 2014 at 2:24 AM, Caitlin Potter <caitpotter88 at>

> An assessor can produce data which is desired serialization, period. For
> instance, a setter might be used to enforce rules on valid values, which
> should still be serialized. A proxy could do this too, but nobody really
> wants to use proxies for everything.
> On the other hand, certain assessor properties you would definitely not
> want to serialize, to avoid providing sensitive, unnecessary, or circular
> data to a serializer. So it's hard to pick the most sensible default.
> I don't think built in accessors really matter much, because things like
> Array length becomes useless when serialized, but user defined accessors
> often aren't useless or undesirable to serialize (at least in data
> persistence libraries and similar things).
> It's hard to produce a cohesive argument or example from a phone, though,
> I'll get back to this on another day.
> On Dec 24, 2014, at 7:47 PM, Andrea Giammarchi <
> andrea.giammarchi at> wrote:
> Out of curiosity, which accessor, being a runtime info that once trapped
> in a static property looses its meaning, is commonly needed for JSON ?
> I am just thinking about `Array` and the fact that thanks gosh the
> `length` is not in. What kind of logic you have in mind?
> ```js
> // to fix the exception
> // with ... a **non enumerable** method ;-)
> class SomeCase {
>   toJSON() {
>     var o = Object.assign({}, this);
>     o.accessor = this.accessor;
>     return o;
>   }
> }
> ```
> case solved in few lines and yet another method, the `toJSON` one, that
> nobody wants to show up anywhere in an enumerable way.
> Best Regards
> On Thu, Dec 25, 2014 at 1:17 AM, Caitlin Potter <caitpotter88 at>
> wrote:
>> Supposing that methods were non-enumerable by default, would accessors be
>> different, or also non-enumerable by default?
>> In most cases, accessors would make sense to be enumerable, e.g. for JSON
>> serialization, but that would be sort of inconsistent and confusing if the
>> default were different from methods
>> (Just thinking out loud)
>> > On Dec 24, 2014, at 7:09 PM, Brendan Eich <brendan at> wrote:
>> >
>> > Brendan Eich wrote:
>> >> There's a confounding variable: the pain of ES6s meta-object APIs, in
>> all respects.
>> >
>> > I meant "ES5's" here, of course.
>> >
>> > Agree with Jeremy, laziness is a programmer virtue and a part of human
>> nature. People are not bothering where they don't know better, or do
>> perhaps know enough but don't have time and cause to take the trouble. The
>> trouble is due to the non-default nature of non-enumerability. Arguing from
>> that past default to (still-future for a little while!) ES6 class's
>> prototype methods being non-enumerable is circular, if you ignore the
>> foolish-consistency argument (which I think we should, but I"m not
>> dismissing here -- just noting that it isn't enough to avoid circularity
>> because of the ES5's-painful-to-use confounder).
>> >
>> > /be
>> > _______________________________________________
>> > es-discuss mailing list
>> > es-discuss at
>> >
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list