Если я в начале скрипта укажу declare(strict_types=1);, и укажу тип для каждого свойства, каждого аргумента каждого метода и его возвращаемый тип, то никаких неявных преобразований не возникнет. В документации это четко указано:
In strict mode, only a value corresponding exactly to the type declaration will be accepted, otherwise a TypeError will be thrown.
Но PHP позволяет не делать этого, что является по умолчанию и чем, собственно, пользуются. Всё зависит от разработчика.
Давайте сойдемся на том, что комьюнити было даже не в курсе, что есть такой нытик, которому подсунули говно под жирным соусом.
А кто из нас петух
У кого что болит, тот о том и говорит. Слышали пословицу? Вас, как будто на зоне заставляли на PHP писать. При чём вообще шахматная доска? Не все на двачах зависают, извините.
Если перефразировать - от языка зависит, сможете ли Вы адекватно реализовать конкретный паттерн на конкретном языке, и нужен ли он Вам. Как пример - тот же синглтон в PHP (да и не только) считается антипаттерном и не используется.
года два назад работал на проекте где основной бекенд это serverless Symfony + bref. Насколько мне известно - до сих пор всё работает и умирать не собирается. А хоронят много кого. Вот PHP, к примеру, уже который год.
А variadic и не нужен. Это как пример. Вариантов, на самом деле достаточно. Можно как аргумент передать коллекцию, в которой все элементы гарантированно будут типизированы. Можно передать простой массив и проверять instance of элемента (или использовать статический анализ). А можно просто вызвать someFun на всех элементах массива, что тоже избавляет от необходимости иметь такой дженерик.
Но в целом Вы правы. Иногда не хватает подобного функционала, но с этим жить можно =)
Практика показывает, что когда возникает подобная необходимость, то там не так уж и много наследников получается, да и поддерживать все-все возможные типы не так уж и нужно.
Вы гребёте всех под одну гребёнку. По Вашим словам - у меня не нормальная работа и вообще я петух со средним IQ =)
Но у меня хорошая и интересная работа, хорошая зарплата, и вообще мне нравится PHP. И если Вы валите из комьюнити не сделав ничего для него, то скатертью дорога, Вас вряд ли будут ждать назад с Вашим "опытом".
Нет, именно так, вроде нельзя. Но с другой стороны, я смогу создать SampleInterface, унаследовать нужные T от интерфейса, и использовать их:
<?php
interface SampleInterface {}
final class SampleString implements SampleInterface {}
function someFun(SampleInterface ...$samples) {}
function someFunString(SampleString ...$stringSamples) {}
Можно быть точно уверенным, что там именно массив элементов, наследующих SampleInterface (someFun) или SampleString (someFunString). В данном случае PHP более "многословен", но вроде как решает задачу. При чём someFunString в принципе и не нужно, если Вам не нужна специфическая реализация. Возможно есть способ и получше. Можно передавать как массив. Тогда нужен докблок (для указания типа элементов) и, возможно, проверка. Костыли, да. Но ведь можно хоть немного абстрагироваться.
Никто не изображает. Она там есть. На проектах, в которых я работаю везде включена строгая типизация и везде используются статические анализаторы (ну и плюс cs, phpunit, deptrac). У Вас не получиться просто взять и передать int, где ожидается string.
В докблок. И использовать статический анализатор. Он не пропустит ничего, кроме int, иначе выдаст ошибку. Да, не совсем то, что ожидалось, но массив int на самом деле редко передаётся. Скорее это будет коллекция по интерфейсу коллекции. И, на самом деле, докблок для типизации редко используется, но бывает, как вот этот конкретный случай. Как минимум, Вы точно не сможете вызвать эту функцию с аргументом, отличным от массива. А то что там инты - берёт на себя анализатор.
В PHP есть строгая типизация (strict_types), правда нет дженериков (которые можно указать в аннотациях). Есть type hint, return type. Есть статические анализаторы phpstan/psalm/phan. В общем, язык сам по себе может обеспечить явную строгую типизацию, имея даже специальное исключение TypeError.
Асинхронность и корутины можно добавить, но если нужен воркер - то тут очевидно лучше выбрать golang, хотя и на PHP всё возможно сделать: файберы, ReactPHP, разные реализации серверов, типа RoadRunner, swoole, в общем - выбор имеется.
То что Вы описали - вечно крутящийся воркер. Да, на PHP тоже такое можно. И, например, прикрутить еще Temporal. да, не просто всё, но можно =)
В целом хочется добавить, что у PHP есть своя ниша. Я считаю, что PHP - хороший язык программирования, который хоть и не идеален, но лично мне нравится таким, какой он есть =)
Остальные места работы на PHP - это параши той или иной засраности, если вы работаете там даже сеньором.
При чём автор, видимо работал на единственном проекте и совсем не факт, что он там видел нормальный PHP:
влезть в PHP по причине жирного проекта, где я и застрял. И я много лет жалею об этом. В этом стэке некуда развиваться. Тут гнобят за развитие и критическое мышление.
И если мы собираемся "разбиваться на кучки (комьюнити)", то я рад, что в "моей кучке" не будет человека, который презирает всех, только "потому что".
Без примеров кода никуда. На PHP можно написать парсилку логов, которая будет кушать память как не в себя, повторяя это на каждой итерации, пока позволяют ресурсы, а можно использовать генератор и быть счастливым. Можно использовать FFI. Можно написать своё расширение на C/C++/Rust (ну просто можно, если хотите).
Если я в начале скрипта укажу
declare(strict_types=1);, и укажу тип для каждого свойства, каждого аргумента каждого метода и его возвращаемый тип, то никаких неявных преобразований не возникнет. В документации это четко указано:Но PHP позволяет не делать этого, что является по умолчанию и чем, собственно, пользуются. Всё зависит от разработчика.
Давайте сойдемся на том, что комьюнити было даже не в курсе, что есть такой нытик, которому подсунули говно под жирным соусом.
У кого что болит, тот о том и говорит. Слышали пословицу? Вас, как будто на зоне заставляли на PHP писать. При чём вообще шахматная доска? Не все на двачах зависают, извините.
Если перефразировать - от языка зависит, сможете ли Вы адекватно реализовать конкретный паттерн на конкретном языке, и нужен ли он Вам. Как пример - тот же синглтон в PHP (да и не только) считается антипаттерном и не используется.
Но паттерн от языка никак не зависит.
года два назад работал на проекте где основной бекенд это serverless Symfony + bref. Насколько мне известно - до сих пор всё работает и умирать не собирается. А хоронят много кого. Вот PHP, к примеру, уже который год.
Смешно, спасибо за Ваше мнение, мне было интересно (нет) =)
Я линуксом пользуюсь. Кроме PHP мне нравятся и другие языки, так что не обобщайте. Снова. Вы слишком многое себе позволяете =)
А variadic и не нужен. Это как пример. Вариантов, на самом деле достаточно. Можно как аргумент передать коллекцию, в которой все элементы гарантированно будут типизированы. Можно передать простой массив и проверять instance of элемента (или использовать статический анализ). А можно просто вызвать someFun на всех элементах массива, что тоже избавляет от необходимости иметь такой дженерик.
Но в целом Вы правы. Иногда не хватает подобного функционала, но с этим жить можно =)
https://bref.sh/
По хорошему такой анализ всегда добавляется в CI =)
Практика показывает, что когда возникает подобная необходимость, то там не так уж и много наследников получается, да и поддерживать все-все возможные типы не так уж и нужно.
Вы гребёте всех под одну гребёнку. По Вашим словам - у меня не нормальная работа и вообще я петух со средним IQ =)
Но у меня хорошая и интересная работа, хорошая зарплата, и вообще мне нравится PHP. И если Вы валите из комьюнити не сделав ничего для него, то скатертью дорога, Вас вряд ли будут ждать назад с Вашим "опытом".
Нет, именно так, вроде нельзя. Но с другой стороны, я смогу создать
SampleInterface, унаследовать нужныеTот интерфейса, и использовать их:Можно быть точно уверенным, что там именно массив элементов, наследующих
SampleInterface(someFun) илиSampleString(someFunString). В данном случае PHP более "многословен", но вроде как решает задачу. При чёмsomeFunStringв принципе и не нужно, если Вам не нужна специфическая реализация. Возможно есть способ и получше. Можно передавать как массив. Тогда нужен докблок (для указания типа элементов) и, возможно, проверка. Костыли, да. Но ведь можно хоть немного абстрагироваться.Это variadic, и
integersбудет именно массивом int. Аргументом функции нельзя будет передать что-либо кроме int.можете пример на другом языке, что именно Вы хотите? В PHP нет дженериков, выкручиваемся как можем =)
Никто не изображает. Она там есть. На проектах, в которых я работаю везде включена строгая типизация и везде используются статические анализаторы (ну и плюс cs, phpunit, deptrac). У Вас не получиться просто взять и передать int, где ожидается string.
Кстати да. Отличный пример, спасибо, я как-то даже не подумал. У PHP, на самом деле, очень много крутых фич подъехало с 8.0/8.1.
Как я говорил, такая типизация в докблоке - редкое явление. Это скорее индикатор того, что можно сделать лучше.
В докблок. И использовать статический анализатор. Он не пропустит ничего, кроме int, иначе выдаст ошибку. Да, не совсем то, что ожидалось, но массив int на самом деле редко передаётся. Скорее это будет коллекция по интерфейсу коллекции. И, на самом деле, докблок для типизации редко используется, но бывает, как вот этот конкретный случай. Как минимум, Вы точно не сможете вызвать эту функцию с аргументом, отличным от массива. А то что там инты - берёт на себя анализатор.
Linux - это ядро GNU, замена Unix, написанное студентом, что бы пользоваться благами сети на домашнем компьютере.
В PHP есть строгая типизация (strict_types), правда нет дженериков (которые можно указать в аннотациях). Есть type hint, return type. Есть статические анализаторы phpstan/psalm/phan. В общем, язык сам по себе может обеспечить явную строгую типизацию, имея даже специальное исключение TypeError.
Асинхронность и корутины можно добавить, но если нужен воркер - то тут очевидно лучше выбрать golang, хотя и на PHP всё возможно сделать: файберы, ReactPHP, разные реализации серверов, типа RoadRunner, swoole, в общем - выбор имеется.
То что Вы описали - вечно крутящийся воркер. Да, на PHP тоже такое можно. И, например, прикрутить еще Temporal. да, не просто всё, но можно =)
В целом хочется добавить, что у PHP есть своя ниша. Я считаю, что PHP - хороший язык программирования, который хоть и не идеален, но лично мне нравится таким, какой он есть =)
В статье откровенный необоснованный хейт:
При чём автор, видимо работал на единственном проекте и совсем не факт, что он там видел нормальный PHP:
И если мы собираемся "разбиваться на кучки (комьюнити)", то я рад, что в "моей кучке" не будет человека, который презирает всех, только "потому что".
Без примеров кода никуда. На PHP можно написать парсилку логов, которая будет кушать память как не в себя, повторяя это на каждой итерации, пока позволяют ресурсы, а можно использовать генератор и быть счастливым. Можно использовать FFI. Можно написать своё расширение на C/C++/Rust (ну просто можно, если хотите).