classes and enumerability

Andrea Giammarchi andrea.giammarchi at
Wed Dec 24 17:39:26 PST 2014

also apologies, generally speaking, I haven't found a way yet to configure
this bloody spellcheck in Epiphany for GNOME 3.14 ... I might park myself
until I can write without 3 mistakes per 5 written chars.

Best Regards

On Thu, Dec 25, 2014 at 2:36 AM, Andrea Giammarchi <
andrea.giammarchi at> wrote:

> 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
> syntax.
> Why carrying old gotchas in is not a good way to clean-up or go toward
> better patterns.
> Cheers
> On Thu, Dec 25, 2014 at 2:24 AM, Caitlin Potter <caitpotter88 at>
> wrote:
>> 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