на тему поддержки генериков в jsx ничего не делают случайно?

нет вроде

Так они в этом случае не нужны. Предназначение абстрактных классов в том, чтобы их нельзя было инициировать, чтобы они могли реализовать внутри общий для потомков функционал и некоторые интерфейсы, которые обязаны определить дочерние классы.

наоборот в этом случае как раз и нужны, я не собираюсь делать new, я хочу сказать, что этому классу соответствует этот объект

А можно подробнее? Потому что не очень понятно пока, если надо сказать, что объект соответствует некоему интерфейсу, обычно пишут интерфейс. Ты собираешься проверять определение абстрактных методов в объекте и делегировать функции из прототипа абстрактного класса объекту?

А можно подробнее? Потому что не очень понятно пока, если надо сказать, что объект соответствует некоему интерфейсу, обычно пишут интерфейс. Ты собираешься проверять определение абстрактных методов в объекте и делегировать функции из прототипа абстрактного класса объекту?

я бы написал интерфейс, но они в рантайме недоступны)

А можно подробнее? Потому что не очень понятно пока, если надо сказать, что объект соответствует некоему интерфейсу, обычно пишут интерфейс. Ты собираешься проверять определение абстрактных методов в объекте и делегировать функции из прототипа абстрактного класса объекту?

нет, я собираюсь на ответ get(SomeAbstractClass) отдать объект

ничего больше происходить не будет)

Тогда зачем тебе абстрактный класс?

Используй обычный

потому что в нем есть абстрактные методы, очевидно же)

Ровно тоже самое, что я приводил в пример.

и потому что именно его нельзя инстанцировать

Инстанцировать можно. Но это заставит ругнуться компилятор ТС

это и есть нельзя)

А в рантайме вообще пофиг, инстанцируй сколько хочешь.

В рантайме можно)

в рантайме и типы обходить можно

это не считается

Короче я понял, тебе нужен ключ указатель на объект

При этом создавать объекты через реальные классы ты не хочешь

Так?

нет

я создаю через реальные классы

Или ты хранишь объекты по ключу прототипа?

Который и есть твой абстрактный класс

да, храню по ключу объекты

но вопрос вообще в том

как описывается абстрактный класс)))

какой тип у абстрактного класса точнее

ну тип “что-то, у чего нет new()” (:

ага и возвращает объект этого типа :)

Так?

у меня потом есть в инициализаторе строчки типа container.bind(AbstractHttpClient, new SuperagentHttpClient);

т.е. все реальное, создается через реальные классы

в шарпе это было просто where T : new(), точнее, в этом случае можно было просто не писать это

Погоди

?

Такой хак получился abstract class Base { abstract foo():string; } class Child extends Base { foo() { return 'foo'; } } const map = new Map<any, any>(); function create<T extends Base>(key:any):T { return map.get(key); } const base = create(Base); // ok const child = create(Child); // ok base.foo(); // ok child.foo(); // ok

Поправил пример

В вебшторме подсказки падают, компилятор не ругается)

Но это если у тебя один абстрактный класс

ну не, у меня куча несвязанного

блин, это вообще конфиг, он не так критичен, потому что эти get вызываются только в нем и буквально в паре мест еще

но так удобно, что компилятор чекал возможные опечатки(

Тады с приведением типа abstract class Base implements IBase { abstract foo():string; } abstract class AnotherBase { abstract bar():number; } class Child extends Base { foo() { return 'foo'; } } const map = new Map<any, any>(); function create<T>(key:any):T { return <T> map.get(key); } const base = create<Base>(Base); // ok const anotherBase = create<AnotherBase>(AnotherBase); // ok const child = create<Child>(Child); // ok base.foo(); // ok anotherBase.bar(); // ok child.foo(); // ok

Хм, а ты странный. Я конфиг сделал просто указывая интерфейс конфига.

Config.get<IApplicationConfig>(filename)

И вынес в итоге в статические шорткаты типа Config.getApplicationConfig()

Хотя, если куча конфигов, да еще и с хелперами каким-то.

В общем бери последний пример

Он рабочий

И подходят любые классы

ну, я имею ввиду конфиг контейнера)

Но надо дублировать

да, понятно, что последний рабочий

я хотел избежать этого явно описав тип абстрактного класса

Ну, может теоретически, если ты создашь базовый абстрактный класс и унаследуешь все остальные от него

тогда и на выходе тип будет только его

не то, что нужно короче)

казалось бы, банальная вещь

))

Вообще странно, что оно не работает.

Вот я тоже думал, что get<T>(thing:T):T вернет тип T

А оно без прямого указания не работает.

мм

Тьфу, запутался я с этими абстрактными классами. Не работает именно для абстрактных классов же.

Хотя, казалось бы, чем не интерфейс.

интерфейс вообще ж недоступен в рантайме

Суть та же, только имеет реализацию.

Не, я не к этому.

Но тебе прям принципиально абстрактный класс сделать?

да нет

мне сам вопрос интересен

как его описать-то

проблем-то подсунуть туда другую реализацию нет вообще)

Я вот не уверен, а в других языках абстракции можно использовать на уровне референсов вообще?

ну да, на этом принципе же работают di-контейнеры

в php например можно у классов и интерфейсов брать их строчный уникальный FQCN

в java тоже есть SomeClass.class

в js как бы есть Function.name, но он ниразу не уникальный :)

в php например можно у классов и интерфейсов брать их строчный уникальный FQCN

Это с каких пор?

с 5.3 наверное, сейчас проверю

Я уже года два толком с ним не работал. Может упустил что.

в js как бы есть Function.name, но он ниразу не уникальный :)

А зачем Function.name, если ссылка всегда уникальная.

это да

Просто в реализации TypeScript почему-то абстрактный класс не дает на выход интерфейс.

ну и к строке уникально привести не проблема

может issue завести?)

Хотя я вот DI делал и без абстракций обошелся.

Не уверен, но мне кажется они тут избыточны и довольно редко нужны.

ну мне просто удобно писать container.get(SomeClass)

и не загоняться)

Ну я так же пишу

У меня по тому же принципу контейнер работают

@inject(ServiceClass) property:ServiceClass

а, я такое не пишу)

Ну я решил почему бы нет)

решил, что лучше все в конфиге руками записать

а в классах вообще никаких намеков на container не делать)