michael.lee.theriot at gmail.com (2016-03-18T15:59:04.854Z)
Try this... It will only seal if calling new (the constructor syntax only allows you to call new as well). The subclasses will still
need to seal though.
```js
'use strict';
class Test {
constructor() {
this.x = 1;
if(new.target === Test) {
Object.seal(this);
}
}
}
class SubTest extends Test {
constructor() {
super();
this.y = 2;
if(new.target === SubTest) {
Object.seal(this);
}
}
}
var st = new SubTest();
st.x; // 1
st.y; // 2
st.z = 3; // throws error
```michael.lee.theriot at gmail.com (2016-03-18T15:46:11.474Z)
Try this... It will only seal if calling new. The subclasses will still
need to seal though.
```js
'use strict';
class Test {
constructor() {
this.x = 1;
if(new.target === Test) {
Object.seal(this);
}
}
}
class SubTest extends Test {
constructor() {
super();
this.y = 2;
if(new.target === SubTest) {
Object.seal(this);
}
}
}
var st = new SubTest();
st.x; // 1
st.y; // 2
st.z = 3; // throws error
```
Try this... It will only seal if calling new. The subclasses will still need to seal though. ```js class Test { constructor() { this.x = 1; if(new.target === Test) { Object.seal(this); } } } ``` On Fri, Mar 18, 2016 at 9:57 AM, Brian Barnes <ggadwa at charter.net> wrote: > Great, glad to hear that's coming! I think sealing is a fine solution, > it'll do what I want and doesn't cause fits for the engine makers. > > That said, it has one problem -- base classes. You can't seal them > because the constructor in the extended class would fail (I tried it) and > so the base classes would always have to remain unsealed which means you > either (1) understand that or (2) always use an extended class if you care > for level of code safety. > > [>] Brian > > > On 3/18/2016 11:50 AM, kdex wrote: > >> Brian, Your first example isn't too far from ES2017. Leave away the >> `let`s and seal it, and you got: >> >> ```js >> "use strict"; >> class Test { >> x = 1; >> y = 2; >> constructor() { >> Object.seal(this); >> this.z = 3; // TypeError >> } >> } >> ``` >> You can already use this using transpilers (at least babel supports it). >> >> On 18.03.2016 15:39, Brian Barnes wrote: >> >>> Ugh, well, I guess I typed a lot of stuff for nothing! And by the >>> look of their experiment, what I wanted was actually one of the major >>> blockers. >>> >>> It seems classes will really need a more standard type of syntax (non >>> static) before you could actually achieve this, and might be a bridge >>> too far for javascript: >>> >>> class test >>> { >>> let x=1; >>> let y=2; >>> constructor() {} >>> func() { this.z=2; } // syntax error >>> } >>> >>> Though it could be kind of faked by some kind of reverse hoisting, >>> i.e., rebuilding the code inside the engine: >>> >>> class test >>> { >>> constructor() >>> { >>> this.x=1; >>> this.y=2; >>> // stuff that was in the constructor >>> Object.seal(this); >>> } >>> ... >>> } >>> >>> [>] Brian >>> >>> On 3/18/2016 10:04 AM, Sébastien Doeraene wrote: >>> >>>> Hi, >>>> >>>> The Strong Mode experiment was canceled: >>>> https://groups.google.com/forum/#!topic/strengthen-js/ojj3TDxbHpQ >>>> >>>> Cheers, >>>> Sébastien >>>> >>>> On Fri, Mar 18, 2016 at 3:59 PM, kdex <kdex at kdex.de >>>> <mailto:kdex at kdex.de>> wrote: >>>> >>>> Already considered and to be implemented via strong mode IIRC. >>>> >>>> On 18.03.2016 14:36, Brian Barnes wrote: >>>> >>>> I know properties on classes are getting a look over for the >>>> next iteration (last I checked) and I understand javascript is >>>> obviously a different language then other oo languages with a >>>> different foundation, but I bring this up for it's usage in >>>> producing stricter code that reduces errors and is easier to >>>> analyze. A vote for this if anybody considered it! >>>> >>>> class Test >>>> { >>>> >>>> constructor() >>>> { >>>> this.x=1; >>>> } >>>> >>>> func1() >>>> { >>>> this.y=2; >>>> } >>>> >>>> func2() >>>> { >>>> console.log(this.x+','+this.y); >>>> } >>>> } >>>> >>>> var test1=new Test(); >>>> test1.func1(); >>>> test2.func2(); // outputs 1,2 >>>> >>>> var test2=new Test(); >>>> test2.func(); // outputs 1,undefined >>>> >>>> I know classes contents are meant to be in strict mode, and I >>>> thinking that only allowing properties to be created in the >>>> constructor (or eventually static properties on the class >>>> itself) would make a system less prone to the conditions like >>>> you see above. Basically, func1() would produce a error when >>>> run. >>>> >>>> I can see why this type of initialization of properties could be >>>> desired, though, especially as it reflect the way it would have >>>> worked if you used a function instead of a class. >>>> >>>> [>] Brian >>>> _______________________________________________ >>>> es-discuss mailing list >>>> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org> >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org> >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> es-discuss at mozilla.org >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss at mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160318/daa8c99b/attachment.html>