AD
Есть ещё полуадхок на перегрузках
Size: a a a
2020 October 22
˸A
зачем наследование?
А я и не про наследование говорил. Композиция? Хорошо - как вы 100500 методов объекта ссылки будете в композите реализовывать? В ТС
extends - это и в типах работает: interface A extends B {x: something} - то же, что type A = B & {x: something}AD
как множественное наследование связано с полиморфизмом?) не вижу связи
Тебе нужно обработать A,B,C ты их наследует от интерфейса
AD
И вызываешь метод
AD
ок, значит джаву не будем использовать.
Не, это просто технические ограничения
˸A
+
Точно так же, как отсутствие async/await (promises) в пхп - "технические ограничения"
Точно так же, как отсутствие async/await (promises) в пхп - "технические ограничения"
АГ
в пхп например, если в классе есть определенный метод - ты можешь сунуть этот класс туда, где этот метод ожидается, и он будет вызван. но нужно не ограничивать тип аргумент метода классом, надо вместо этого лучше использовать интерфейс. т.к. интерфейс реализовать может любой класс. а вот унаследоваться от класса не любой класс может.
SP
в пхп например, если в классе есть определенный метод - ты можешь сунуть этот класс туда, где этот метод ожидается, и он будет вызван. но нужно не ограничивать тип аргумент метода классом, надо вместо этого лучше использовать интерфейс. т.к. интерфейс реализовать может любой класс. а вот унаследоваться от класса не любой класс может.
То есть надо забить на типы что бы забить на типы
АГ
+
Точно так же, как отсутствие async/await (promises) в пхп - "технические ограничения"
Точно так же, как отсутствие async/await (promises) в пхп - "технические ограничения"
так есть же промисы в пыхе - вон в газле
SP
так есть же промисы в пыхе - вон в газле
Угу, и они все такие совместимые между собой
АГ
То есть надо забить на типы что бы забить на типы
надо заменить зависимости от классов на зависимости от интерфейсов, если надо иметь несколько классов, разных, реализующих этот интерфейс. да, под это придется осознанно заложиться.
SP
В js тоже был период когда промисы не являлись частью спецификации
АГ
в го проще с этим - если нужные методы реализованы - значит и интерфейс реализован
SP
в пхп например, если в классе есть определенный метод - ты можешь сунуть этот класс туда, где этот метод ожидается, и он будет вызван. но нужно не ограничивать тип аргумент метода классом, надо вместо этого лучше использовать интерфейс. т.к. интерфейс реализовать может любой класс. а вот унаследоваться от класса не любой класс может.
То что ты упоминал это duck typing, так в руби любят.
˸A
в пхп например, если в классе есть определенный метод - ты можешь сунуть этот класс туда, где этот метод ожидается, и он будет вызван. но нужно не ограничивать тип аргумент метода классом, надо вместо этого лучше использовать интерфейс. т.к. интерфейс реализовать может любой класс. а вот унаследоваться от класса не любой класс может.
О, так у нас теперь только интерфейсы - типы, а классы.... недотипы, что ли?))))
АГ
То что ты упоминал это duck typing, так в руби любят.
ага, если не указать у аргумента тип, а оставить mixed, то можно сунуть туда любой класс с нужным методом, и все сработает.
АГ
но это не очень хорошо, потому что реальной инфы о типе нет. лучше интерфейсы все-таки делать
АГ
О, так у нас теперь только интерфейсы - типы, а классы.... недотипы, что ли?))))
ну вот ты допустим хочешь а и б тип иметь. при этом а и б - классы. теперь вопрос - что эти классы делают? почему нельзя создать 2 интерфейса с теми же методами, и не написать класс, имеющий все поля классов а и б, и реализующий оба интерфейса, и использовать его там?
АГ
да, придется убрать требование "дай мне а" на требование "дай мне интерфейс а"
АГ
порефачить придется. но это вроде не большая проблема