In my own code I tend to do the constructor/executor pattern:
```
class A {
constructor(exec) {
this.a = 1;
exec(this);
Object.freeze(this);
}
}
class B extends A {
constructor() {
super(() => {
this.b = 2;
});
}
}
```
And it works out pretty well.
On Fri, Mar 18, 2016 at 11:25 AM, kdex <[email protected]> wrote:
> 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]> 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 < <[email protected]>[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
>>
>
>
>
> _______________________________________________
> es-discuss mailing
> [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
