> it becomes awkward in javascript when time comes
> around to serializing/reconstructing the custom array-type
To be honest, I've found that overriding `toJSON()` and providing some
static helpers for your `JSON.parse()` reviver lead to pretty expressive
(de)serializability:
class MySerializableArray extends Array {
toJSON() {
return {
$type: this.constructor.name,
items: Object.values(this)
}
}
static isSerializedInstance(val) {
return typeof val === 'object' &&
val.$type === 'MySerializableArray' &&
Array.isArray(val.items);
}
}
const reviver = (key, val) => {
if (MySerializableArray.isSerializedInstance(val)) {
return new MySerializableArray(...val.items);
}
return val;
};
const instance = new MySerializableArray('a', 'b', 'c'),
serialized = JSON.stringify(instance),
parsed = JSON.parse(serialized, reviver);
https://jsbin.com/kasiwevobo/edit?js,console
If that's too much boilerplate for you, there's probably some low hanging
fruit for a decorator implementation that generalizes some reasonable
default serialization behavior.
On Sat, Nov 25, 2017 at 2:14 AM, kai zhu <kaizhu...@gmail.com> wrote:
> it may be standard-operating-procedure to sub-class builtin arrays in
> other languages. but it becomes awkward in javascript when time comes
> around to serializing/reconstructing the custom array-type while
> baton-passing it around frontend<->backend<->database via JSON.
>
> On 11/3/17, Andrea Giammarchi <andrea.giammar...@gmail.com> wrote:
> > I agree with everything else you said but since you mentioned the word
> > "misinformed" I'd like to improve this misleading sentence:
> >
> >> It's 99% sugar over the existing prototype-based model
> >
> > This has been one of the most misunderstood and undertaken parts of ES6.
> >
> > Classes are *not* just sugar, thinking about classes as just sugar that
> can
> > be replicated on ES5 is FUD and even if I've pointed out Babel
> > documentation has a wrong description of classes it's still there and 99%
> > of developers believe classes are like that, just sugar over prototypal
> > inheritance.
> >
> > This is so wrong that TypeScript fails with the most basic extend:
> >
> > ```js
> > class List extends Array { method() {} }
> >
> > (new List) instanceof List; // false
> > (new List).method(); // throws because it's not a List so no method
> > ```
> >
> > To simulate ES2015 classes you need `Reflect.construct`, unavailable in
> > ES5.
> > Polyfilling Reflect.construct with ES5 features is not enough: you need
> > Symbols too.
> >
> > Symbols are technically impossible to polyfill (i've gone very close, yet
> > not a perfect poly).
> > Symbols are needed to keep the instance so that in a transpiled world:
> >
> > ```js
> > (new List).slice() instanceof List; // true
> > ```
> >
> > Most developers that went for classes have broken code out of the box
> > thanks to transpilers and yet at the end of 2017 we keep writing that ES
> > classes are just sugar on top of ES5.
> >
> > We should stop starting from this ML to keep spreading this wrong
> > information.
> >
> > Thank you all for your understanding.
> >
> > Regards
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Nov 3, 2017 at 4:49 AM, Isiah Meadows <isiahmead...@gmail.com>
> > wrote:
> >
> >> Honestly, this entire thread reads as partially misinformed,
> >> borderline trollbait. These kinds of questions and thoughts should
> >> really be asked directly (and a bit more respectfully) to TC39
> >> representatives and/or put in blog posts wherever. es-discuss is
> >> primarily about language design, and although the subject implies it's
> >> about the language's design in the abstract, I'm not convinced the
> >> content and responses really are.
> >>
> >> 1. Claims of a language "civil war" don't belong on this list, and are
> >> objectively false. Yes, there's disagreement, but even TC39 members
> >> aren't exactly in agreement here - consider the difference between
> >> Lodash/Ecmarkdown (Domenic Denicola) and Ecmarkup (Brian Terlson).
> >> Please take that into account.
> >> 2. Yes, there are multiple idiomatic uses of JavaScript, but it's
> >> large enough you can carve out a subset and be done with it. You don't
> >> like classes? Don't use them. You don't like arrow functions? Don't
> >> use them. You don't like `array.map`? Don't use it. Just because they
> >> exist doesn't obligate you to use them, and they don't hurt you in any
> >> way if you don't. Also, complaints of a person's or group's choice of
> >> idiom do *not* belong on this list whatsoever. Leave that crap to a
> >> private message, a blog post (if it's a group), or whatever.
> >> 3. JavaScript "classes" are not technically class-based OOP, and TC39
> >> members have acknowledged this in blog posts. It's 99% sugar over the
> >> existing prototype-based model, just with easier native subclassing.
> >> You could in theory replicate this in the rest of the language with a
> >> combination of `Object.defineProperty`, `Object.setPrototypeOf`,
> >> `new.target`, and existing ES5.
> >> -----
> >>
> >> Isiah Meadows
> >> m...@isiahmeadows.com
> >>
> >> Looking for web consulting? Or a new website?
> >> Send me an email and we can get started.
> >> www.isiahmeadows.com
> >>
> >>
> >> On Thu, Nov 2, 2017 at 4:32 PM, doodad-js Admin <dooda...@gmail.com>
> >> wrote:
> >> >
> >> > -----Original Message-----
> >> > From: Claude Petit [mailto:p...@webmail.us]
> >> > Sent: Thursday, November 02, 2017 4:24 PM
> >> > To: 'kai zhu' <kaizhu...@gmail.com>; 'es-discuss' <
> >> es-discuss@mozilla.org>
> >> > Subject: RE: javascript vision thing
> >> >
> >> > For mostly real OOP under JS, please see my project (doodad-js). But I
> >> can't warranty its future without a custom language because nobody on
> >> TC39
> >> want to works along-side with me on that project, and they are making
> >> their
> >> own supposed "classes" which are not.
> >> >
> >> > -----Original Message-----
> >> > From: kai zhu [mailto:kaizhu...@gmail.com]
> >> > Sent: Wednesday, November 01, 2017 11:43 PM
> >> > To: es-discuss <es-discuss@mozilla.org>
> >> > Subject: javascript vision thing
> >> >
> >> > any thoughts? i'll break the ice with a quora question i recently
> >> answered
> >> >
> >> > quora question:
> >> >> Why is JavaScript so hated?
> >> >
> >> > answer posted:
> >> >>the primary reason is because traditional oop skills gained from
> >> c#/c++/java/python/etc translate poorly to javascript.
> >> >>
> >> >>in javascript, class-instantiated objects are inferior to
> >> >> plain-objects,
> >> because plain-objects come with JSON.stringify/JSON.parse baked-in,
> while
> >> classes require needless extra serialization/deserialization routines
> >> which
> >> can easily double your codebase or more (as real-world javascript-code
> is
> >> heavily i/o based). i would say many people burn-out from
> >> frontend-programming because they can’t cope with debugging all the i/o
> >> edge-cases serializing/deserializing their custom classes.
> >> >>
> >> >>javascript and frontend-programming is essentially about efficiently
> >> managing the program-state like a baton, constantly passing it
> >> back-and-forth between the browser’s ui and various backend-servers /
> >> persistent-storage. plain json-objects utilizing idiot-proof
> >> JSON.stringify/JSON.parse, are naturally better at this baton-passing
> >> business than writing classes with custom serializers.
> >> >
> >> >
> >> >
> >> > there's currently a civil war going on in frontend-development,
> between
> >> those who don't want to deal with writing extra class-based
> >> serializers/deserializers and those who do. these 2 different design
> >> patterns have incompatible styleguides that often break web-projects
> when
> >> people try to mix-and-match both together. i don't have a simple
> >> solution
> >> to this issue, but tc39 should be made aware of it as they try to
> >> formulate
> >> a javascript vision that doesn't alienate frontend-development.
> >> >
> >> > -kai
> >> >
> >> >
> >> >
> >> > ---
> >> > This email has been checked for viruses by AVG.
> >> > http://www.avg.com
> >> >
> >> > _______________________________________________
> >> > es-discuss mailing list
> >> > es-discuss@mozilla.org
> >> > https://mail.mozilla.org/listinfo/es-discuss
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss@mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >>
> >
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
--
Jeremy Martin
661.312.3853
@jmar777 <https://twitter.com/jmar777> / @j <https://stream.live/j>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
