> I feel ES classes are overly restrictive in preventing
> this, since it basically forces you to force subclasses to do
> something like `this.init()` right after the class is allocated,
> leaking implementation details left and right.
its not a design-flaw. the flaw is you trying to shoehorn “classical”
inheritance-based design-patterns on a language better suited to use
static-functions to baton-pass json-data (over class-instance).
here’s a real-world example of a ```dbTableCreateOne``` static-function to
initialize a mongo-like collection/table, and then sync it with indexeddb
persistence-store [1]. imagine how much more difficult these [common-case]
async-initializations would be using inheritance-based constructors.
```javascript
local.dbTableCreateOne = function (options, onError) {
/*
* this function will create a dbTable with the given options
*/
var self;
options = local.objectSetOverride(options);
// register dbTable
self = local.dbTableDict[options.name] =
local.dbTableDict[options.name] || new local._DbTable(options);
...
// restore dbTable from persistent-storage
self.isLoaded = self.isLoaded || options.isLoaded;
if (!self.isLoaded) {
local.storageGetItem('dbTable.' + self.name + '.json', function (error,
data) {
// validate no error occurred
local.assert(!error, error);
if (!self.isLoaded) {
local.dbImport(data);
}
self.isLoaded = true;
local.setTimeoutOnError(onError, 0, null, self);
});
return self;
}
return local.setTimeoutOnError(onError, 0, null, self);
};
```
p.s. - going off-topic, but above-mentioned code/library (as well as proposals
for standard tree/stl libraries) shouldn’t even exist if javascript had a
builtin/standard sqlite3 library (like python).
[1] initialize a db-table and sync it with persistence-store
https://github.com/kaizhu256/node-db-lite/blob/2018.4.23/lib.db.js#L1861
<https://github.com/kaizhu256/node-db-lite/blob/2018.4.23/lib.db.js#L1861>
[2] discuss including tree and stl in proposed standard-library
https://github.com/tc39/proposal-javascript-standard-library/issues/16#issuecomment-457833409
<https://github.com/tc39/proposal-javascript-standard-library/issues/16#issuecomment-457833409>
https://github.com/tc39/proposal-javascript-standard-library/issues/16#issuecomment-461285304
<https://github.com/tc39/proposal-javascript-standard-library/issues/16#issuecomment-461285304>
> On 9 Feb 2019, at 4:18 AM, Isiah Meadows <[email protected]> wrote:
>
> I've also had *several* scenarios where I could've used this
> personally. I feel ES classes are overly restrictive in preventing
> this, since it basically forces you to force subclasses to do
> something like `this.init()` right after the class is allocated,
> leaking implementation details left and right.
>
> -----
>
> Isiah Meadows
> [email protected]
> www.isiahmeadows.com
>
> On Fri, Feb 8, 2019 at 1:22 AM #!/JoePea <[email protected]> wrote:
>>
>> I many times find myself in cases where a base class wants to ensure that
>> logic is always fired after the current method's execution, so that for
>> example no matter in which order sub classes call the `super` method, the
>> `super` method can still guarantee that logic fires after the whole stack of
>> the same method in the class hierarchy.
>>
>> So what I can do now is use `Promise.resolve().then(() => { ... })` to
>> schedule that logic for later, that way all the invocations of a `foo`
>> method along the class hierarchy have all fired. But this means that other
>> code can also fire before the next microtask.
>>
>> Is there some way to do it? If not, I wonder if some language feature for
>> doing it would be possible?
>>
>> - Joe
>> _______________________________________________
>> 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
