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 < [email protected]> 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 ES.next 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 <[email protected]> > 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 < >> [email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 >>> > [email protected] >>> > https://mail.mozilla.org/listinfo/es-discuss >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
