Bradley, looks like you have a typo and should be using the `this` argument
you pass to `exec` rather than `this` in the arrow?
```
class B extends A {
constructor() {
super(inst => {
inst.b = 2;
});
}
}
```
On Fri, Mar 18, 2016 at 8:27 AM, Bradley Meck <[email protected]>
wrote:
> 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
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
