ll work as expected.
>>>>
>>>> On Thu, Aug 30, 2018 at 4:38 PM doodad-js Admin
>>>> wrote:
>>>>
>>>>> I'm late to the party, but I've found a solution for my non-loved
>>>>> framework : have another constructor called befo
ut I've found a solution for my non-loved
>>>> framework : have another constructor called before "super", which fills a
>>>> faked "this" and a faked "args" then replicated values to "this" after
>>>> doing "super(..
;, which fills a
>>> faked "this" and a faked "args" then replicated values to "this" after
>>> doing "super(...fakedArgs)".
>>>
>>>
>>> https://github.com/doodadjs/doodad-js/blob/v9.1.3/src/common/Bootstrap.js#L5320
;> https://github.com/doodadjs/doodad-js/blob/v9.1.3/src/
>> common/Bootstrap.js#L5320-L5330
>>
>> -Original Message-
>> From: Isiah Meadows
>> Sent: Sunday, August 26, 2018 3:29 PM
>> To: Logan Smyth
>> Cc: Ben Wiley ; es-discuss <
;super", which fills a
>> faked "this" and a faked "args" then replicated values to "this" after
>> doing "super(...fakedArgs)".
>>
>>
>> https://github.com/doodadjs/doodad-js/blob/v9.1.3/src/common/Bootstrap.js#L5320-L5
tstrap.js#L5320-L5330
>
> -Original Message-
> From: Isiah Meadows
> Sent: Sunday, August 26, 2018 3:29 PM
> To: Logan Smyth
> Cc: Ben Wiley ; es-discuss <
> es-discuss@mozilla.org>
> Subject: Re: constructor, super, and data members issue
>
> Yeah, I was
ps://github.com/doodadjs/doodad-js/blob/v9.1.3/src/common/Bootstrap.js#L5320-L5330
-Original Message-
From: Isiah Meadows
Sent: Sunday, August 26, 2018 3:29 PM
To: Logan Smyth
Cc: Ben Wiley ; es-discuss
Subject: Re: constructor, super, and data members issue
Yeah, I was more focused on
Yeah, I was more focused on the static class side of things, because I
thought they were referring to that. Class instance fields are
different, and so of course, those are never set on the prototype
unless for whatever reason, the parent constructor returns
`Object.getPrototypeOf(this)` instead
Static class fields run their initializers and define the properties at
declaration time, and class constructors have the parent class as the
`[[Prototype]]`, so static field values are inherited. I think this is
adding to confusion though, because while that's absolutely true, that is
not
Every object, including functions, have an internal prototype. Functions
normally have one set to `Function.prototype`, and objects normally inherit
from `Object.prototype` at least indirectly. But because of how prototypes
work, the only requirement for something to be used as a prototype is that
How can they be prototypically inherited if they don't live on the
prototype? I feel like I'm missing something.
Le sam. 25 août 2018 19 h 53, Isiah Meadows a
écrit :
> Class fields are prototypically inherited just like via `Object create`.
> This is more useful than you might think, and it's
Class fields are prototypically inherited just like via `Object create`.
This is more useful than you might think, and it's the main reason anyone
actually cares about static fields beyond namespacing.
On Sat, Aug 25, 2018 at 14:36 Ben Wiley wrote:
> All this just reminds me of *my opinion* that
All this just reminds me of *my opinion* that class fields is a borrowed
concept from statically typed languages that is misplaced in a dynamically
typed languages like JavaScript.
In C++ I use class fields to declare what properties will be allocated and
instantiated when a new class member is
24-08-2018 19:29, Aaron Gray :
>
> Yeah it does look like its badly "broken by design".
>
Why this behaviour is broken? Every OOP language that I worked with
behaves de same way, and there's not many developers complaining about
it. If you want to use a property that might be overrided in a
Base cases that take dependencies upon information potentially supplied by
subclass have to be intentionally design to make that work. And the chosen
design should be document as part of its subclassing contract. For the example
shown there is there is a long known pattern that can be used:
On Sat, 25 Aug 2018 at 00:35, Logan Smyth wrote:
> Generally if something is required during construction, it would be best
> to pass it down as part of the constructor options. For example, you could
> do
> ```
> class Base {
> constructor({ idAttribute = "id"}) {
> this.idAttribute =
Personally I think a design where the superclass relies on any part of the
subclass is "broken by design"; but certainly there's ways you can achieve
that.
On Fri, Aug 24, 2018 at 4:34 PM, Logan Smyth wrote:
> Generally if something is required during construction, it would be best
> to pass it
Generally if something is required during construction, it would be best to
pass it down as part of the constructor options. For example, you could do
```
class Base {
constructor({ idAttribute = "id"}) {
this.idAttribute = idAttribute;
}
}
class Derived extends Base {
constructor() {
Yeah it does look like its badly "broken by design".
On Fri, 24 Aug 2018 at 22:13, Jordan Harband wrote:
> I'm afraid that still wouldn't solve the problem; the superclass's code is
> all 100% completed before the subclass has `this` available.
>
> On Fri, Aug 24, 2018 at 1:52 PM, Ranando King
I'm afraid that still wouldn't solve the problem; the superclass's code is
all 100% completed before the subclass has `this` available.
On Fri, Aug 24, 2018 at 1:52 PM, Ranando King wrote:
> Aaron, congratulations! You just tripped over a new reason for me to
> revive issue #123. The only way
Aaron, congratulations! You just tripped over a new reason for me to revive
issue #123. The only way to get that to work is to have the default values
on the prototype. The problem comes because `this` doesn't even have a
value until the last call to `super()` returns. If a `class` doesn't have a
I am having an issue with order semantics regarding
https://github.com/tc39/proposal-class-fields with derived classes defining
or overriding data member values that are used in the base class
constructor for initialization of properties of the class.
This means the Super Class / Base Class'es
22 matches
Mail list logo
