Как стать автором
Обновить

Комментарии 42

Объединение типов, серьезно? PHP, куда ты катишься…
ЗЫ: Сори, к Сторму вопросов нет.

А почему нет? Например, в тех же тестах часто есть конструкции вида MyClass|TestObject и теперь это можно законно использовать на уровне языка, а не аннотаций.

Жалко, что архитектура языка, заявленного как язык с динамической типизацией, все больше обрастает костылями. Напоминает этот советский мультфильм.

Сколько лет развития прошло с момента, когда считалось, что динамическая типизация — это круто?
Как мне кажется, общество определенно поддерживает стремление к строгой типизации. И, как по мне, это очень здорово, люблю предсказуемый код.

Не понятно зачем тогда нужен PHP когда есть в плане типов и строгости есть достойные кандидаты

Никто не принуждает вас использовать строгую типизацию.

Вопрос не в принуждении, а в том куда развивается язык и в его консистентности

И в чем консистентность языка страдает? В том, что одновременно с типами и без можно писать? На проекте с более чем одним разработчиком это решается линтингом.
Я вам не оппонирую, правда интересно разобраться, кому могут быть неудобны типы в PHP и почему.

Именно что страдает консистентность. Вы можно писать с типами можно без, с strict_types и без и это не только в вопросе типов.
Не подумайте я не против типов. Просто существуют инструменты которые гораздо лучше решают эту проблему

Во-первых, с появлением возможности указывать типы язык не перестал быть языком с динамической типизацией.


Во-вторых, есть немало проектов, которые переписывать никто не будет, а вот внедрить в них потихоньку типизацию с целью увеличения качества кода вполне можно.


В-третьих, типизация не делает язык лучше всех остальных, она лишь привносит ещё одно улучшение, которое можно применять с целью сделать свой код качественнее.

Проблема не в типах как feature, проблема в том что усидеть на двух стульях не получится. Либо гарантии как в строго типизированных статических языках (+ все накладные на работу с типами), либо type hinting который в лучшем случае что то гарантирует

Судя по всему, php постепенно и придет к тому, что типы будут везде. Уже сейчас в большинстве проектов считается обязательным как минимум для нового кода использовать типизацию. Пока ещё невозможно это делать для переменных, но думаю, что и там тоже типы добавятся со временем.


Не думаю, что язык когда-либо станет строго типизированные, поскольку это сломает обратную совместимость в куче проектов, но то, что через некоторое время типы будут применяться повсеместно, это точно. И скорее всего такой код будет работать быстрее, чем код без типов.

Какие из интерпретируемых ООП?

Typescript, например.
Кроме того, я не отличу в работе Python с MyPy от PHP 8 (первый будет даже выразительнее). Правда, Python комьюнити намного хуже относится к типизации, чем РНР. Поэтому более вероятно подключить библиотеку без меток типов.
Впрочем, РНР в чем-то уникален — runtime проверки типов. Это допускает запуск с некорректными системе типов состояниями, но убирает возможность их появления.

TypeScript как язык строго компилируемый, не так ли?

А почему именно интерпритируемые? Вам шашечки или ехать, хотите корректности и проверки на уровне типов, gcи тд — берите java,c# etc. Нужна динамика и строгость + функциональная парадигма, а еще что бы работа с многопоточностью из коробки — берете elixir, erlang. Как говорится best/right tool for the job

Потому что это удобно.


А, как показывает практика, проверк атпов вполне работает в рантайме, а не только в компайлтайме.

2020 продолжает удивлять

"Строгая" типизация, пришедшая в PHP 7.4 больше добро, чем зло. Мы рефакторили легаси проект, который был написан во времена PHP 5.2 и 7.4 с ее типизацией очень сильно помогла. К примеру, мы знаем, что в этом свойстве будет int, тут будет объект, функция может вернуть только определенный объект и все это без PHPDoc.


Если проект крупный, то строгая типизация лично мне помогает быстрее понять суть.


Жаль, что в PHP 8 не будет точно такого же синтаксиса обобщений, как в Java или C#.

Жаль, что в PHP 8 не будет точно такого же синтаксиса обобщений, как в Java или C#.
Не самого интересного, по-моему (не то, что я их хорошо знаю, но вроде там простой как валенок).
Пусть будет синтаксис, как в Typescript.
С переходом с 2019.3 на 2020.1 шторм стал жутко тупить. Так что пользоваться им было практически невозможно.
Подскажите, в 2020.2 глюки с 2020.1 тоже перенесли или стоит попробовать обновится?
Не вот этот баг, часом? Если оно — то это рантайм, который можно поменять в < 2020.1.3 парой ударов по бубну. В 2020.1.3 вроде поправили, в 2020.2 не замечал пока.
Да, симптомы сходятся. Спасибо за информацию.
Был очень рад, когда объявили поддержку OpenAPI.
Но после тестов разочаровался. Автодополнение работает не везде и местами странно (например в $ref:). Нет поддержки $ref на другие файлы — без этого весь плагин бесполезен. Разве что у вас в проекте пару эндпоинтов. Пока остаюсь на другом плагине.

А меня обрадовало что починили наконец иконку закрытия табов редактора.
Наконец можно обновить на 2020.

Список изменений внушительный, хорошая работа!

Из личного опыта:

  1. окно IDE при открытии файла из проводника в Windows всё также не фокусится
  2. очень хочется пункт Show in Project в меню таба редактора (про иконку мишени уже знаю)

есть хоткей Alt+F1,1 выполняет ту же функцию.

Перестал знать стандартные функции пхп. Файл на месте /snap/phpstorm/current/plugins/php/lib/php.jar
Мы пока не понимаем, почему это происходит. Судя по всему, стопроцентно помогает ручной снос папки idea.system.path/caches, но не File | Invalidate Caches / Restart | Invalidate and Restart.

Нет в меню vcs->git show pull requests

Возможно вы открыли проект в котором нет remote на github?


есть :), у меня в этом меню ниже ребейза нет пунктов. версия:
PhpStorm 2020.2
Build #PS-202.6397.115, built on July 29, 2020
Licensed to ********
You have a perpetual fallback license for this version
Subscription is active until August 1, 2021
Runtime version: 11.0.7+10-b944.20 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Linux 5.4.0-42-generic
GC: ParNew, ConcurrentMarkSweep
Memory: 1936M
Cores: 6
Current Desktop: ubuntu:GNOME
Если у вас git remote -v в этом проекте действительно показывает ремоут на GitHub, и плагин GitHub не выключен в Settings | Plugins | Installed, то надо смотреть детально. Отправьте пожалуйста логи (Help | Collect Logs and Diagnostic Data) в Help | Contact Support.
Ожидается ли поддержка такого функционала для Gitlab? Нашел несколько issues, но открыты они были давно или и без ответа.

Пропал автокоплит поиска ветки при git pull, я не одинок в этом ?

Комплишена как будто бы и раньше не было, в 2020.1 в диалоге в принципе не было поля для ввода имени ветки. Но я не вижу причин не сделать комплишен, поэтому вот.
Caarl Извиняюсь, я промахулся с комментарием, сообщение предназначалось вам.

Помогло, большое вам спасибо !

После обновления на 2020.2 «залипает» проверка php кода через CS, т.е. IDE подчеркивает ошибку вроде «phpcs: Function closing brace must go on the next line following the body; found 1 blank lines before brace» — исправляешь, а ошибка остается на месте, пока файл не переоткроешь.
А у вас всё-всё локальное, и сам проект (в том смысле, что это не замаученная шара или что-то такое), и сам PHP_CodeSniffer?
Если так, помогает ли File | Reload All from Disk?
А, кажется я наткнулся на эту проблему на нашем трекере: youtrack.jetbrains.com/issue/WI-53963
Ждём, пока разработчик перенесёт фикс в 2020.2.
у меня в логе такой ошибки нет, пытался записать скринкаст, но баг какой-то плавающий
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.