A
Size: a a a
2020 July 27
A
идешка видит что не то делаешь / стат анализаторы проверяют и находят что не то делаешь, и оповещают об этом. а если проигнорить - то на этапе выполнения возникнет ошибка... вроде как очеивидно все... не пойму, в чем затык то у меня...
Эти генерики нужны для того, чтобы показать статическому анализатору/компилятору как связаны типы и как их выводить.
A
Я выше кинул пример их использования.
АГ
а если уйти от скалярных типов, и заменить T, B на интерфейсы? не пойдет такое?
АГ
короче как я понял, если по сути, вся эта шумиха вокруг дженериков обусловлена манипуляциями со встроенными типами (скалярными, либо другими массив, объект). при манипуляции с классами / интерфейсами такой проблемы нет.
АГ
если внедрить концепцию "все объект" (условно) т.е. 2->multiply(2) === 4 - то и у скалярных объектов появится некий интерфейс, и проблема уйдет? необходимость в дженериках отпадет?
A
а если уйти от скалярных типов, и заменить T, B на интерфейсы? не пойдет такое?
Как?
A
короче как я понял, если по сути, вся эта шумиха вокруг дженериков обусловлена манипуляциями со встроенными типами (скалярными, либо другими массив, объект). при манипуляции с классами / интерфейсами такой проблемы нет.
Неправильно =\
A
а если уйти от скалярных типов, и заменить T, B на интерфейсы? не пойдет такое?
Там вся фишка именно в зависимости на уровне типов. Т.е. мы вы Collection<A> можем передать только функцию которая принимает A и возвращает какое-то B. И вернет этот метод именно Collection<B>.
Как это интерфейсами выразить?
Как это интерфейсами выразить?
A
Тэкс, ты видимо дальше на дискуссию не настроен. Пойду я тогда.
AM
Да вот не скажи. Много ты языков с вытесняющими грин тредами знаешь?
Есть мнение, что они не нужны
A
Есть мнение, что они не нужны
Не нужны грин треды? Или не нужны вытесняющие грин треды?
АГ
Тэкс, ты видимо дальше на дискуссию не настроен. Пойду я тогда.
в 4 утра что-то жестко дискутировать) вместо функции можно передать тоже объект-преобразователь, можно завернуть в объекты все. есть же распространенная "хорошая" практика заворачивать айдишники в классы, так что вполне нормально вокруг скаляра класс делать... видимо я упускаю какие-то моменты, но у нас же, если мы работаем с абстракциями, как раз все в порядке с архитектурой. а шаблоны завязаны на конкретику
A
в 4 утра что-то жестко дискутировать) вместо функции можно передать тоже объект-преобразователь, можно завернуть в объекты все. есть же распространенная "хорошая" практика заворачивать айдишники в классы, так что вполне нормально вокруг скаляра класс делать... видимо я упускаю какие-то моменты, но у нас же, если мы работаем с абстракциями, как раз все в порядке с архитектурой. а шаблоны завязаны на конкретику
Ну покажи, как по-твоему будет выглядеть мой пример с контейнером.
АГ
т.е. как бы в момент объявления там завязка на абстракцию (тип) а в момент конкретного применения на уровне кода (не на уровне рантайма) там уже идет замена на что-то конкретное... вот и не пойму зачем это, когда можно оставить все зависимости на интерфейсы, и перевести только на рантайм эти вещи...
АГ
попозже напишу код...
АГ
в том примере идет замена T на B. т.е. видимо подразумевается, что это разные интерфейсы. а зачем так осуществлять преобразование? почему бы не написать просто TToBConverter{.. convert(T $t):B; }, где T и B это интерфейсы?
АГ
разные типы, в данном случае я идеалистически заменяю на разные интерфейсы
АГ
если ввести такие интерфейсы как Any, Scalar, Number и т д
A
в том примере идет замена T на B. т.е. видимо подразумевается, что это разные интерфейсы. а зачем так осуществлять преобразование? почему бы не написать просто TToBConverter{.. convert(T $t):B; }, где T и B это интерфейсы?
Ты попробуй написать аналог того кода сначала.