Foo.getList(Bar) Foo.getList(String) Foo.getList(Number) всё будет подхватываться автоматически

Не, не, оно надо всегда Bar.getList() возвращающий список Bar'ов или один Bar (ну может быть функция get/getList/getById и т.п.)

static getList<U,W> U - тип конструктора, что мы передаём, W - его входные параметры. Второй даже не обязательно, но так подсветка синтаксиса полнее)

Baz.getList должен возвращать инстанцы Baz'ов и т.п.

Не, ну это понятно.

Ну вот на примере какого-нибудь ActiveRecord в пэхапэ

Какой угодно конструктор пиши)

php Users::findById()->name

А тут получается надо заморочиться Users.findById(Users)().name

Ну и проще свести тогда к простому Foo.get<Foo>().fooProperty

Так что тут походу от миксинов не уйти

Ну и проще свести тогда к простому Foo.get<Foo>().fooProperty

Что проще - когда дженерик подхватывается сам, или когда его каждый раз надо писать самому?)

Да где же он у тебя сам-то подхватывается?

let val = Foo.getList(Bar)('Moscow','New York');

Просто в твоем примере конструктор передается и тут дженерик не нужен

так просто active record не нужен

Просто в твоем примере конструктор передается и тут дженерик не нужен

А ты случайно не без них изначально хотел? ?

Да мне ActiveRecord и не нужен.

Мне подобие ODM нужно

ну вообще видимо красивее всего через generic

причем, если методов статических много, то вероятнее правильно было бы вынести все статические в отдельный интерфейс

потому что вероятно будут случаи, когда захочется отдельный объект делать с таким интерфейсом

ну вообще видимо красивее всего через generic

Плохо через генерик, слишком многословно получается.

Без миксина никуда

Нет позднего статического связывания или его аналога

а issue есть?

В Mongoose подобная задача так и решается.

Есть issue

ой, а скинь линк

Плохо через генерик, слишком многословно получается.

ну вообще половина кода там это для документации

Ну так да, но это самый частый случай. Чаще будет getList напрямую вызываться, по аналогии метода findOne у моделей в монгусе.

А ещё обрати внимание на x=>[x.hello,x.id] из разных классов

Ну так да, но это самый частый случай. Чаще будет getList напрямую вызываться, по аналогии метода findOne у моделей в монгусе.

Bar.getIds();

М - многословность))

Еще раз, Bat.getIds будет вызываться в коде 1 раз из 100 раз Bar.getList.

Аналог - модель findOne в Mongoose.

ой, а скинь линк

https://github.com/Microsoft/TypeScript/issues/5863#issuecomment-165388445

Собственно, там по ссылке самый простой пример того, что я хочу.

Не то, но аналог того, что нужно.

А в Mongoose это сделано следующим образом (если вкратце) interface Model<T extends Document> model<D, S>(schema) Model<D> & S { ... } const myModel = model<{prop:string}, {staticMethod...}>(schema) Model.findOne().exec().then(x => console.log(x.prop))

Еще раз, Bat.getIds будет вызываться в коде 1 раз из 100 раз Bar.getList.

let getList = (constr)=>constr.getList(constr); getList(Bar) x100 begin; Я наверное чего-то не понимаю ?

Ага

Мне нужен getList в статических методах наследника

А не отдельно

Плюс

А я не в статическом методе наследника сделал?

Таких методов 10 штук, мне надо вот эти связывания делать в 100 файлах по 10 раз в каждом?

Для простоты, есть один базовый класс, в нем 10 статических методов, есть 100 наследников этого класса. Эти 100 наследников в коде вызывают от 10 до 100 раз методы базового класса.

Собственнь, Bar.getList(Bar) или дублировать в 100 наследниках код функцию getList.

Выглядит как костыль.

Хотя в нормальных языках решается за раз два

Выглядит как обращение к статическому методу ?

И зачем тебе дублировать getList? Я его в дочернем классе не дублировал

хе, теперь с this type получилось красивее организвать cucumber сценарии

И зачем тебе дублировать getList? Я его в дочернем классе не дублировал

Чтобы не писать Bar.getList(Bar) же, мне надо его переопределить в Bar на static getList => Foo.getList(Bar)

Я вот реально не понимаю, почему TS не хочет. Мы же в static getList имеет this в виде конструктора класса наследника.

Должно быть что-то вроде getList(): {new(): this}

Чтобы не писать Bar.getList(Bar) же, мне надо его переопределить в Bar на static getList => Foo.getList(Bar)

static getIds() { let val = Foo.getList(Bar) Так и было изначально. В дочернем классе мы можем вызывать любой класс, Foo.getList, Bar.getList - это не важно, всё уже работает

Поэтому похоже придется использовать миксины и this type.

Должно быть что-то вроде getList(): {new(): this}

Оно и есть (construct:{new(storage:W):U}) Просто эту конструкцию достаточно написать один раз

static getIds() { let val = Foo.getList(Bar) Так и было изначально. В дочернем классе мы можем вызывать любой класс, Foo.getList, Bar.getList - это не важно, всё уже работает

Вот удали getIds из примера вообще. Представим что такой метод есть у одного из 20 наследников.

Оно и есть (construct:{new(storage:W):U}) Просто эту конструкцию достаточно написать один раз

Не один раз же

Каждый раз A.getList(A), B.getList(B)

N.getList(N)

Зачем туда N, если он и так this === N?

Вот удали getIds из примера вообще. Представим что такой метод есть у одного из 20 наследников.

Любой наследник может вызывать этот код из любого места внутри себя

Да не нужно мне внутри него!

Мне нужно у наследников снаружи этот метод вызывать же

И получать их инстансы

А вот Flow меня понимает! https://tryflow.org/?code=Y2xhc3MgRm9vIHsKICAgIGlkOm51bWJlcjsKICAgIAogICAgc3RhdGljIGdldExpc3QoKTpBcnJheTx0aGlzPiB7CiAgICAgICAgcmV0dXJuIFtuZXcgdGhpcygpXTsKICAgIH0KfQoKY2xhc3MgQmFyIGV4dGVuZHMgRm9vIHsKICAgIGhlbGxvOnN0cmluZzsKICAgIAogICAgc3RhdGljIGdldElkcygpIHsKICAgICAgICByZXR1cm4gdGhpcy5nZXRMaXN0KCkubWFwKHggPT4geC5pZCk7CiAgICB9Cn0KCkJhci5nZXRMaXN0KCkubWFwKHggPT4gY29uc29sZS5sb2coeC5oZWxsbywgeC5pZCkpOw==

Flow умный, будь как Flow!

Это мне WebStorm сказал на мой пример на Flow

Хотя на типы не ругается, но автокомплит не робит

И вообще фигня какая-та

Зато в песочнице на tryflow все ок

ну так webstorm не поддерживает flow

И получать их инстансы

инстансы кого?

наследников?

это просто синтаксис

Я уже понял)

наследников?

Да

ну это даже на словах тупо получается. Если у тебя есть статические методы для обработки чего-то там со стороны, то будь добр туда пробрасывай параметром то, что хочешь обработать, или биндь, или ещё как-нибудь, но примешивать статические методы в другой класс, чтобы их не писать — очень-очень-очень плохая идея

Да на надо ничего примешивать. Средствами JS это все делается без проблем, если TS выкинуть.

Вот прям простой пример class Foo { static getList() { return [new this, new this]; } } class Bar extends Foo {} console.log(Bar.getList());

А вот для TS вынь и подай Bar.getList<Bar>()

Мне нужно у наследников снаружи этот метод вызывать же

У меня такое ощущение, что ты меня толсто троллишь ?

У меня такое ощущение, что ты меня толсто троллишь ?

Вовсе нет) И я на самом очень благодарен за попытку помочь, но мы с тобой друг друга недопоняли.

Теперь для того, чтобы Bar создал пару инстансов Bar не нужно даже скобки писать Bar.getIds Куда уж дальше)

Я там выше писал, выкинь getIds

Оставь функции исключительно в родительском классе

И вызываться они будут через дочерний класс снаружи где-то в модулях.