Treesitter нужно ставить обязательно с markdown и markdown_inline, это необходимо чтоб корректно отображались подсказки документации по методам, аргументам и тд. Для того чтоб показывались подсказки в режиме ввода можно использовать ray-x/lsp_signature.nvim
Intelephense умеет в автоматическое форматирование php файлов и в исправление форматирования, можно сделать например так:
function PhpFormatting()
if &ft == 'php'
lua vim.lsp.buf.format()
endif
endfunction
autocmd BufWritePre *.php call PhpFormatting()
Для приятно работы с references и implementations можно использовать dnlhc/glance.nvim ну это субъективно.
Помощником с проектами на php может стать ta-tikoma/php.easy.nvim : создание классов с учетом области имен из composer.json и упрощение работы с удалением\копированием\добавлением методов\свойств\констант.
И в финале: пригодится L3MON4D3/LuaSnip для ускорения написания кода через снипеты.
у http клиента от laravel есть метод retry который позволяет повторить запрос сколько угодно раз, а так же обрабатывать ошибку по необходимости, я думаю это подошло бы на случай когда "моргнула сеть"
Если проводить аналогию с реальным миром то контракт, как докумен, сам не следит за исполнением обязательств описанных в нем, по сему это больше похоже на интерфейс, а не на класс, который содержит реализацию.
Целью статьи как раз является введение в данную тематику, чтоб составить общее представление и были средства "с чего начать".
Ссылки не указал потому как подумал что это может считаться рекламой (по названию пакеты можно найти). В первоначальной версии статьи на каждый из пунктов "что проверять" я добавлял пример кода как именно это проверить, но убрал, так как возможно это было бы навязывание конкретного решения.
Я рассказал, для тех кто ещё не писал тесты архитектуры приложения: для чего их писать, с помощью чего и какое развитие может быть у данной категории тестов.
Из пояснений не ясно какого размера у вас модули, есть какой либо критерий по объёму когда один модуль следует разбить на два?
Я использую схожую идею разделения на модули, но в проектах на laravel. Для себя выделил следующие правила:
Если требуется общение между модулями то осуществлять их через контракты. Чтоб проще было определить границы его влияния, а так же подменить на другой модуль.
Модели, а в вашем случае сущности, не должны быть частью модуля, а должны лежать в общей папке и доступны всем модулям (отсылка к гексоганальной архитектуре где база это одна из граней). В процессе разработке таблицы в базе обростают связями и становится невозможным обособить конкретные таблицы в одном модуле. Другой подход породит чрезмерное дублирование описания таблиц в каждый модуль.
С какого то момента wildberries заселили всевозможные мелкие поставщики причём загрузка товаров прошла без всякой валидации в итоге когда ищешь одежду у тебя в фильтре "хлопок", "хопок", "холопок", "хлоппокпок" ... . С тех пор сервисом стало просто не приятно пользоваться, благо в нашем захолустье открыли пункт ozon.
Указание свойств в конструкторе мне тоже не по душе (потому что для меня это выглядит не очевидным что это объявлены свойства объекта).
Скажу в защиту readonly, на сколько я понимаю, ключевое слово постулирует о том что php будет проверять что свойство было заполнено единожды и более изменяться не будет. В то время как в вашем варианте "неродивый" разработчик мог добавить в ваши объекты публичный сеттерт то с readonly это ему не поможет.
Статья интересная, хотел бы предложить на ваше рассмотрение два своих подхода:
Проверка данных в методе
Предлагаю не проверять внутри метода возможность его совершения. Рассмотрим предложенный вами пример с заказом. Выдачей сущностей у нас заведует репозиторий и я предлагаю в зависимости от статуса выдавать разные сущности унаследованные от одной основной, с той разницей что у DeliveredOrder не будет иметь метода cancel. То есть мы уже на уровне типизации защитимся от этого невозможного вызова.
Проверка данных в конструкторе
Я бы все же предложил переложить валидацию данных на билдер для конкретного класса. Например Собака не содержит в себе информацию о том как проверить набор веществ для своего создания, это в её "создателе" (да это тоже Собака, но ссылка на другой объект) произошла проверка что вещества подходят ли и в нужном ли количестве для создания Собака. А она уже содержит набор правил по взаимодействую с миром к тому что она ходит, а не летает например (ну это уже относится к первому пункту).
спасибо за ваш ответ.
к сожелению я не готов конкретно с вами продолжить дискуссию. я не вижу каких либо новых доводов с вашей стороны, а повторять вышесказанное бесмысленно.
да я могу не пользоваться этим, но идея приложения как раз в том чтоб пользовались(по этому претензии именно к пхпшторм) и это вырабатывает некий паттерн поведения: написания(излишнего на мой взгляд) кода который меня и бесит
Нет, вы исказили мои слова.
Я думал, выше уже довольно подробно указал свою претензию.
Я не против комментариев, когда они действительно нужны. Но я против тех что необходимы только для иде.
Если этого мало то еще (что часто замечаю за пользователями пхпшторма) комментарии дублирующие уже указанные типы атрибутов метода либо его ответа.
Treesitter нужно ставить обязательно с markdown и markdown_inline, это необходимо чтоб корректно отображались подсказки документации по методам, аргументам и тд. Для того чтоб показывались подсказки в режиме ввода можно использовать
ray-x/lsp_signature.nvim
Intelephense умеет в автоматическое форматирование php файлов и в исправление форматирования, можно сделать например так:
Для приятно работы с references и implementations можно использовать
dnlhc/glance.nvim
ну это субъективно.Помощником с проектами на php может стать
ta-tikoma/php.easy.nvim
: создание классов с учетом области имен из composer.json и упрощение работы с удалением\копированием\добавлением методов\свойств\констант.И в финале: пригодится
L3MON4D3/LuaSnip
для ускорения написания кода через снипеты.у http клиента от laravel есть метод retry который позволяет повторить запрос сколько угодно раз, а так же обрабатывать ошибку по необходимости, я думаю это подошло бы на случай когда "моргнула сеть"
выглядит, как ситуация доступная для статического анализа, нет ли инструментов для его проведения?
можно ещё проверять является ли файл изображением, ну думаю "и так сойдёт"
Если проводить аналогию с реальным миром то контракт, как докумен, сам не следит за исполнением обязательств описанных в нем, по сему это больше похоже на интерфейс, а не на класс, который содержит реализацию.
Целью статьи как раз является введение в данную тематику, чтоб составить общее представление и были средства "с чего начать".
Ссылки не указал потому как подумал что это может считаться рекламой (по названию пакеты можно найти). В первоначальной версии статьи на каждый из пунктов "что проверять" я добавлял пример кода как именно это проверить, но убрал, так как возможно это было бы навязывание конкретного решения.
В превью статьи есть краткое описание о чем она.
Я рассказал, для тех кто ещё не писал тесты архитектуры приложения: для чего их писать, с помощью чего и какое развитие может быть у данной категории тестов.
Из пояснений не ясно какого размера у вас модули, есть какой либо критерий по объёму когда один модуль следует разбить на два?
Я использую схожую идею разделения на модули, но в проектах на laravel. Для себя выделил следующие правила:
Если требуется общение между модулями то осуществлять их через контракты. Чтоб проще было определить границы его влияния, а так же подменить на другой модуль.
Модели, а в вашем случае сущности, не должны быть частью модуля, а должны лежать в общей папке и доступны всем модулям (отсылка к гексоганальной архитектуре где база это одна из граней). В процессе разработке таблицы в базе обростают связями и становится невозможным обособить конкретные таблицы в одном модуле. Другой подход породит чрезмерное дублирование описания таблиц в каждый модуль.
Из 17-ого года : https://habr.com/ru/post/320114/ ничего не поменялось
С какого то момента wildberries заселили всевозможные мелкие поставщики причём загрузка товаров прошла без всякой валидации в итоге когда ищешь одежду у тебя в фильтре "хлопок", "хопок", "холопок", "хлоппокпок" ... . С тех пор сервисом стало просто не приятно пользоваться, благо в нашем захолустье открыли пункт ozon.
Можно придумать, главное что у нас появится способ указать для иде что мы сейчас хотим написать и на после последней > она будет подсказывать методы.
А если бы внутри вводилась бы какая то псевдо типизация то как бы хорошо это отразилось на активрекорд, когда мы сейчас пишем свойство так:
Можно было писать:
А внутри была бы проверка псевдотипа:
Интересно как иде будет чувствовать себя с
Почему бы не ввести сразу какой то синтаксический сахар для имени метода объекта (а за одно и свойства) типа:
Указание свойств в конструкторе мне тоже не по душе (потому что для меня это выглядит не очевидным что это объявлены свойства объекта).
Скажу в защиту readonly, на сколько я понимаю, ключевое слово постулирует о том что php будет проверять что свойство было заполнено единожды и более изменяться не будет. В то время как в вашем варианте "неродивый" разработчик мог добавить в ваши объекты публичный сеттерт то с readonly это ему не поможет.
Статья интересная, хотел бы предложить на ваше рассмотрение два своих подхода:
Предлагаю не проверять внутри метода возможность его совершения. Рассмотрим предложенный вами пример с заказом. Выдачей сущностей у нас заведует репозиторий и я предлагаю в зависимости от статуса выдавать разные сущности унаследованные от одной основной, с той разницей что у DeliveredOrder не будет иметь метода cancel. То есть мы уже на уровне типизации защитимся от этого невозможного вызова.
Я бы все же предложил переложить валидацию данных на билдер для конкретного класса. Например Собака не содержит в себе информацию о том как проверить набор веществ для своего создания, это в её "создателе" (да это тоже Собака, но ссылка на другой объект) произошла проверка что вещества подходят ли и в нужном ли количестве для создания Собака. А она уже содержит набор правил по взаимодействую с миром к тому что она ходит, а не летает например (ну это уже относится к первому пункту).
Проблему повторения группы правил, как писал выше - создайте UpdateEmailRequest extends FromRequest и используйте его для проверки email
Я понял почему не сделали разбиение на UpdateNameRequest, UpdateEmailRequest, UpdateAgeRequest унаследованных от FormRequest
к сожелению я не готов конкретно с вами продолжить дискуссию. я не вижу каких либо новых доводов с вашей стороны, а повторять вышесказанное бесмысленно.
да я могу не пользоваться этим, но идея приложения как раз в том чтоб пользовались(по этому претензии именно к пхпшторм) и это вырабатывает некий паттерн поведения: написания(излишнего на мой взгляд) кода который меня и бесит
Нет, вы исказили мои слова.
Я думал, выше уже довольно подробно указал свою претензию.
Я не против комментариев, когда они действительно нужны. Но я против тех что необходимы только для иде.
Если этого мало то еще (что часто замечаю за пользователями пхпшторма) комментарии дублирующие уже указанные типы атрибутов метода либо его ответа.