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 <[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]>
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
_______________________________________________
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
