Another way that allowed you to use `new` on both base and derived
classes would be something like this:
```js
"use strict";
function sealInstance(bool) {
if (bool) {
Object.seal(this);
}
}
class Base {
x = 1;
constructor(seal = true) {
sealInstance(seal);
}
}
class Derived extends Base {
y = 2;
constructor(seal = true) {
super(false);
sealInstance(seal);
}
}
let b = new Base(); // Base class can be instantiated with sealing
let d = new Derived(); // Derived class can be instantiated with sealing
```
Not a particular esthetic way, but it doesn't break `new` and transpiles
without private fields.
(It will make your constructor signatures a little ugly, though.)
On 18.03.2016 16:10, Michael Theriot wrote:
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 <[email protected]
<mailto:[email protected]>> 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
<https://groups.google.com/forum/#%21topic/strengthen-js/ojj3TDxbHpQ>
Cheers,
Sébastien
On Fri, Mar 18, 2016 at 3:59 PM, kdex <[email protected]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> 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
[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[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
