Комментарии 48
Дженерики. Сразу за ними подтянутся типизированные коллекции.
Движение в сторону асинхронности. Возможно путем выноса компилятора и VM в специализированные, доступные для запуска из самого PHP, "расширения". И обязательно обмен сообщениями между ними. Как минимум возможность запускать IO в отдельном потоке с возможностью дальше по коду дождаться результата. Вынос GC в отдельный поток(если он еще не там — не уверен)
В совсем далеком будущем — переработка VM. Текущие опкоды довольно костыльны и слишком толсты.
Спецификация на VM. Разные реализации, не прибитые гвоздями к структурам и макросам zend_*
Расширения можно будет писать на самом PHP, компилить в промежуточный код и в таком виде подключать — дальше пусть JIT работает.
Да, дженериков больше всего не хватает.
На втором месте отсутствие аналога public readonly или public final свойств: очень утомляет писать эти дурацкие геттеры для банальных immutable data objects.
Со статическим анализом и PhpStorm неплохо справляется, но это все… такое.
Я лучше геттеров нагенерю, надёжнее.
Со статическим анализом и PhpStorm неплохо справляется
Ну как сказать… Psalm далёк от идеала и вообще языков в которых это из коробки, но PhpStorm даже с ним с равнение не идёт.
Шторм даже за типами свойств не следит, и не подсветит такую простую штуку как запись в свойство значение неверного типа, или обращение в свойству которое может быть null(и EA extended тоже, по крайней мере в бесплатной версии). Object-like arrays им никак не покрыть, да и дженерики в psalm ± есть.
И билд зафейлить не поможет если кто-нибудь сделает что-то нехорошее.
А вообще неплохо если JB возьмутся таки впилить нормальную поддержку language-server-protocol в IDE( LSP Support plugin работает так себе, впрочем, и пилится одним человеком в свободное время ).
Это у вас че-то плохо настроено, у меня и за типами свойств следит, а уж за null-ами тем более. Может, инспекции отключены, или версия php в настройках проекта не та?
<?php
declare(strict_types=1);
class SomeClass {
/**
* @var int|null
*/
private $someVal;
public function __construct(?int $someVal)
{
$this->someVal = $someVal;
}
public function doSomethingUseful(): int {
return $this->someVal + $this->someVal;
}}
Ошибок типов не показывает.
P.s. И да, с фидбеком там всё уже нормально(тык тык тык)
Отток сильных инженеров из php в более востребованные/хайповые языки, снижение популярности.
Думаю, тут дело не столько Вузах и программа от компаний (в конце концов этого и раньше не было и это не помешало php стать массовым), сколько в том, что да — сильные инженеры переходят на другие стеки, роль языка с быстрым стартом для новичков перехватил js (чтобы начать что-то писать на js и базовая алгоритмика -достаточно браузера) +фактор размера рынка и зарплат + "суть" проектов на рынке.
Но возможно, загляну на митап — вдруг тоже ништяк дадут
Так и есть. PHP — это либо суппорт уже давно понаписанного, либо когда заказчик требует. Добровольно на PHP новые проекты уже мало кто знающий другие языки начинает. :-)
Больше оптимизаций и статанализа в компайлтайме, после этого типизированные переменные и дженерики. Вероятно появление понятия пакета/модуля/приложения на уровне языка.
Паралельно нормальная поддержка многопоточности и серверы из коробки.
Основные конкуренты TypeScript и Go.
«Уйдут сильные специалисты» — придут другие. Хайп приходит и уходит, жизнь в IT не раз это показало.
Аргумент так аргумент. Если кто-то говорит что есть технология лучше чем используемая, нужно сказать что это лишь хайп и поставить собеседника в неудобное положение.
Ссылаться при этом на некий опыт — обязательно. Примеры — не нужны.
Как там нынче у Ruby дела, с которого все «за хайпом» на Эликсир бежали?
Всё зависит от задач. Есть круг задач для которых php и его инфраструктура топ — например небольшие и средней величины проекты в вебе. JS с гошечкой еще долго не смогут конкурировать в этой нише по разным причинам.
Доказывать тут лучше PHP или хуже не очень хочется, холивар таки.
Но мой субъективный опыт и наблюдение за происходящим в мире говорит о том, что от задач ничего не зависит в процентах так 99 случаев, и берётся то, во что умеют разработчики, или что там нравится нынче самому авторитетному человеку(читай человеку с самой высокой должностью по технической части). Никакого анализа конечно же не происходит.
Или берётся PHP потому что на краткосрочной дистанции разработчики дешевле, а что там после будет — неважно.
И ещё «небольшие и средней величины» это растяжимое понятие, генерировать backend-CRUDы сегодня очень много вариантов.
Вообще, мне Kotlin весьма нравится. Не монструозный как Java и все фичи которых мне в php не хватает, присутствуют. Ещё C# неплох хоть и с особенностями.
А то что Go подходит для описания бизнес логики приложения — есть сомнения, не берусь утверждать.
Или берётся PHP потому что на кратосрочной дистанции разработчики дешевле, а что там после будет — неважно.
В этом плане JS вообще ничем не лучше. Большой проект на JS/TS имеет не меньше шансов стать тем еще адком, а возможно и больше, учитывая кол-во велосипедов, которые придется написать, так как инфраструктура в целом хуже.
Большой проект на JS/TS имеет не меньше шансов стать тем еще адком, а возможно и больше, учитывая кол-во велосипедов, которые придется написать, так как инфраструктура в целом хуже.
А с чем там проблемы?
Мне кажется небольшому проекту много не нужно, а для крупных — PHP, скажем так, тоже не блещет обилием всевозможных инструментов/интеграций etc.
5.3 мне больше запомнился. Можно сказать как раз тогда детство закончилось у него.
Детство закончилось, когда выпилили register global и magic quotes. Дальше уже юность с подростковыми комплексами ;)
По аналогии с \MyClass::class.
Очень поможет при рефакторинге и переходе в IDE из файлов роутинга.
т.е. сейчас я могу сделать rename у класса, и все упоминания \MyClass::class поменяются на \MyNewClass::class. Было бы круто уметь такое для методов класса, т.к. все еще в некоторых местах названия методов содержатся в строках (роутинг яркий пример).
Что будет с PHP через 5 лет: мы спросили докладчиков ближайшего московского митапа