TypeScript was just an example, but being class a different Syntax beast than just prototype (right?) why would that be bad? It will be indeed not-unexpected as Kevin mentioned later on.
Using classes thinking prototypes feel something developers won't do (specially new comers) so TypeScript behavior looks OKish to me, but in ES7 doesn't have to be like that, it can be actually part of the prototype if you prefer, and do a copy of non primitives ( or leave the Kevin's mentioned footgun in, I don't mind, it never hurt me personally :-) ) Regards On Tue, Jun 9, 2015 at 5:18 PM, Mark S. Miller <[email protected]> wrote: > > > On Tue, Jun 9, 2015 at 9:13 AM, Andrea Giammarchi < > [email protected]> wrote: > >> Mark, properties on the prototype are in TypeScript, and probably every >> other OOP based language. Defaults can be easily defined as such, i.e. >> >> ```js >> class Person { name = 'anonymous'; age = 0; } >> ``` >> > > > At <http://www.typescriptlang.org/Playground>, putting this code into the > left pane causes the right pane to show > > > var Person = (function () { > function Person() { > this.name = 'anonymous'; > this.age = 0; > } > return Person; > })(); > > > which clearly indicates that these are *not* properties on the prototype. > They are per-instance, but merely written with a confusing syntax that > misled you into believing that they were properties on the prototype. > > > > >> Not only, defaults could be optimized upfront by parsers without needing >> to infer or do extra analysis on the constructor. >> >> Defaults also as static property/state is quite common. >> >> ```js >> class Admin { PRIVILEGES = 'all'; } >> ``` >> >> Anyway, I'm curious to know why do you think getters and setters are OK >> and properties are not. I don't see any technical difference, specially >> considering get/set for lazy property computation/assignment through the >> prototype getter anyway. >> >> JS4lf ... you hit an already opened door about strict descriptors, >> already proposed years ago ;-) >> >> >> https://github.com/WebReflection/define-strict-properties#define-strict-properties >> >> Best Regards >> >> >> >> >> >> >> On Tue, Jun 9, 2015 at 4:44 PM, Mark S. Miller <[email protected]> >> wrote: >> >>> On Tue, Jun 9, 2015 at 8:30 AM, Luke Scott <[email protected]> wrote: >>> [...] >>> >>>> It currently uses `=` to define properties. And there is some debate >>>> whether or not properties should be initialized in the constructor or be on >>>> the prototype. >>>> >>> >>> >>> There is no debate about whether per-instance state (of whatever form) >>> can be initialized in the constructor. Often, this needs to be initialized >>> to some value dependent on the values of the constructor parameters. Given >>> that we have no choice about supporting initialization in constructors, the >>> debate is *only* about whether we should also bother to support >>> initialization in the class body outside the constructor. IMO, no. Why add >>> a redundant and less expressive mechanism? >>> >>> As for properties on the prototype, these are rarely enough motivated >>> that doing it imperatively after class initialization seems fine. I don't >>> recall anyone strongly advocating that we need syntactic support for >>> properties on the prototype, though perhaps I missed it. >>> >>> >>> -- >>> Cheers, >>> --MarkM >>> >>> >> > > > -- > Cheers, > --MarkM >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
