Причем тут шаблоны

При том, что ковариантность и контравариантность это про шаблоны

Нет

Это про наследование офк

И ты говоришь, что T либо ковариантный, либо контравариантный

Шаблоны вообще не при чем

Мне кажется ты взял первый попавшийся пример из википедии и неправильно интерпретировал

И от этого зависит, что чей подтип, либо List<Object> подтип List<String>, либо наоборт List<String> подтип List<Object>

А скинь тогда другое определение ковариантности

> Variance refers to how subtyping between more complex types relates to subtyping between their components

где там слово шаблон)

да я ща пример скину

https://repl.it/@AndreyVolkov/Contrvariant

т.е. в пхп нельзя уточнить, что у нас коту не абстрактный Food приходит, а конкретный Meat. Поэтому приходится food херачить как в интерфейсе

https://repl.it/@AndreyVolkov/Contrvariant

Попался Andrey Volkov Contrvariant'ович

Все верно, ковариантность применима в этом контексте, а я был неправ

Только получается PHP в этом плане для входных параметров инвариантен, потому что нельзя заменить ни Food на Meat ни Meat на Food

В методе eat()

Да, нельзя

т.е. наследование для типов аргументов и возвращаемых типов не работает в пхп совсем

Кроме конструкторов

Пишет википедия

в плане аргументов конструктора PHP ковариантен

Срсли? Интересно

Вот это плохо. Кот не 'nom nom'))

https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science) вот тут в середине

Впринципе ковариантность в конструкторе наверное не ломает type safety

стоп, а конструктор жеж и в интерфейс не запихнешь)

ну, если по правильному

конструкторы не часть интерфейса объекта же

но вообще факт интересный

да

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

https://wiki.php.net/rfc/return_types

так и есть да

> The enforcement of the declared return type during inheritance is invariant; this means that when a sub-type overrides a parent method then the return type of the child must exactly match the parent and may not be omitted. If the parent does not declare a return type then the child is allowed to declare one.

я уже выше об этом сказал)

Да

не заметил

Спасибо что помогли понять почему всё так происходит

Вот RFC, про который выше говорили уже https://wiki.php.net/rfc/parameter-no-type-variance В 7.2 можно удалять тип из аргументов

Настоящую вариантность написано там не сделаешь в PHP потому что сложно технически

Я жду типизацию свойств наконец, что бы можно было выкинуть геттеры с сеттерами (по крайней мере в 90% случаев)

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

зачем ждать? бери сишарп и пиши, фулл типизация

ноу сенкс

зачем ждать? бери сишарп и пиши, фулл типизация

Или тс)

если я и буду изучать другой яп, то с другой парадигмой

Вот RFC, про который выше говорили уже https://wiki.php.net/rfc/parameter-no-type-variance В 7.2 можно удалять тип из аргументов

это исключительно для bc и никак иначе, имхо, использоваться не должно

почему

ну это впиливали для DateTime судя по описанию, но почему нельзя это юзать? Ведь LSP не нарушается в этом случае

http://www.dabeaz.com/coroutines/Coroutines.pdf вроде кто-то спрашивал что почитать про елды - я так понимаю это про них. Во всяком случае 5-ый слайд мне понравился :D

Шикарная презентация. Спс

Получается в моем случае не указывать тип и делать проверку внутри метода?

да

либо подумай над архитектурой подольше, потому что по итогу такие задачи меня приводили к более лучшему решению

Шикарная презентация. Спс

там ещё 2 есть на этом сайте про то же примерно =)

99 слайдов за глаза. Прикольно, то что показаны примеры, которые позже фигурирует у Н. Попова в статье про мультизадачность

ну это впиливали для DateTime судя по описанию, но почему нельзя это юзать? Ведь LSP не нарушается в этом случае

написано же зачем впиливали Implementing this RFC would allow libraries to be upgraded to use type declarations in their method signatures. Currently adding types to a method of a class in a library would break any code that extends that class. This would provide an easier upgrade path for libraries to start using scalar types, to replace manual checks being done inside the methods, without requiring an update for all sub-classes.

Кто может помочь

Кто может помочь

Чип и Дейл, очевидно

В версии 5.6 код PHP определялся так: <?php , <? ... Перешёл на версию 7.0 теперь код определяется только так <?php

Можно как-то сделать чтоб определялся <? ..

использование short синтаксиса считается очень плохой практикой, этого лучше избегать (<?)

Почему

более того, вроде бы в 7.2 выпилили его

^ вот поэтому

ERROR: S client not available

использование short синтаксиса считается очень плохой практикой, этого лучше избегать (<?)

Кроме вывода же

В html

В html

изыди, извращенец

<?= ?> - это другое

Я свой проект сделал с <? , решил перейти на php7 а тут это не работает

вообще, https://stackoverflow.com/questions/2185320/how-to-enable-php-short-tags

изыди, извращенец

<?= ?> лучший друг

но лучше замени у себя все на <?php ибо это не последний раз, когда ты с этим сталкиваешься

Также как <? if ?> <? endif?> форыч и тд

https://softwareengineering.stackexchange.com/questions/151661/is-it-bad-practice-to-use-tag-in-php

В этой статье тупа срачи

Я использовал <? и никаких проблем не возникало

<?= ?> - это другое

И да в 7.0+ это все робит

Так же с <?=

Я использовал <? и никаких проблем не возникало

Ну если ты это всегда использовал то фу

Это плохая практика

Переписывай

Почему плохая то?

Потому чтто умные дяди сказали

Во всех манулах где есть краткий синтаксис говорится что его не надо юзать

потому, что это называется "единым стандартом"

Еще например <?xml с шорт синтаксисом php будет пытаться выполнить

<?= такого нет, его в общем можно использовать, но в будущем его вроде тоже могут выпилить

Я использовал <? и никаких проблем не возникало

Теперь вот возникла;)

https://www.php-fig.org/psr/psr-1/

пункт 2.1

Почему плохая то?

это ответ на этот вопрос

<?= такого нет, его в общем можно использовать, но в будущем его вроде тоже могут выпилить

Учитывая что его юзают абсолютно все, не думаю что его выпилят

Это придется тонны вывода переворачивать)

Учитывая что его юзают абсолютно все, не думаю что его выпилят

абсолютно все его стараются обходить стороной

и вообще юзать шаблонизаторы надо в 2018

Еще например <?xml с шорт синтаксисом php будет пытаться выполнить

А если к примеру я не использую другие такие же синтаксисы