господа перфекционисты, накидайте голосов на тикет: https://youtrack.jetbrains.com/issue/WI-38997 вкратце - исправление неконсистентной генерации пхпдока для null|string и null|object

господа перфекционисты, накидайте голосов на тикет: https://youtrack.jetbrains.com/issue/WI-38997 вкратце - исправление неконсистентной генерации пхпдока для null|string и null|object

я @return юзаю только если нужно уточнить тип элемента массива

при виде кода, где на половине доки есть, а на половине нету, начинает глаз дёргаться)

но вот когда я работал в однйо фин организцаии там прям в кодстайлах были обязательные коменты

там еще срачик был нифиговый

в итоге их хуярили там гед они не нужны и получался вот такой пзидец: /** * Делает некоторео действие над пользователем * * @param User $user Юзер * @return bool успешно ли было совершено действие */ public function makeSomeAction(User $user):bool { }

Марко хорошо накинул тогда http://ocramius.github.io/blog/eliminating-visual-debt/

Кто знает автоматический способ удалить ненужные комментарии? Например @param можно точно грохнуть и ничего не будет

не всегда, там может быть описание важно человеческим языком

Всем привет! Разбираюсь сейчас с Doctrine. Прочитал вот эту статью http://ocramius.github.io/blog/doctrine-orm-optimization-hydration/ Проблему понял, но не понял его решение(Coding multi-step hydration in Doctrine ORM). Типа если мы делаем join через dql он нам соберет user и связь socialAccounts, а потом выполнив еще один select partial, он в уже имеющуюся коллекцию юзеров сумеет докинуть session связи? И хотелось бы ваше мнение узнать по этому всему...

Не знаю актуально ли еще. Doctrine дает возможность получить вложенный массив из связанной сущности. Если в схеме стоит связь OneToMany то по этому полю вернется массив объектов. Главное через querybuilder не указывать выборку по полям, иначе чепуха получится. И опосайся перегрузки, если большая вложенность данных. Может тупо падать из-за большого количества. Тогда нужно делать ограничения на глубину.

Возможно есть пример как использовать doctrine на больших нагрузках? типа best practices или брать doctrin-у под большие нагрузка это дичь?

orm с нагрузками связана примерно никак. всё в конечном счёте упирается в использование. Если ты в оперативку грузишь тысячи объектов, то сам себе буратино, как бы. если строишь запросы с 20 джоинами, то сосбсна следом

ну а нахера тебе доктрина, что бы на морде вывести 100 записей?

Ну тоесть для просто выплюнуть содержимое doctrine избыточна, правильно?

Ну вот где она прям очень помогает\

всё, где нужен uow

А конкретнее что выберешь, если в проекте больше 1 чела в команде и уже есть доктрина с зависимостями: - db native-driver - pdo - dbal - саму доктрину уже отмели ???

всё, где нужен uow

ничего из выщеперечисленного))

градус интриги нарастает

у меня просто чуть более наркоманская система, дбал не подходит)

Я так понимаю, что если бы был dbal с асинхровщиной и подходящий инфраструктурой, то был бы рад.

Ну вот если надо на морде вывести 100 записей. Есть doctrine и сайт нагруженный. Как бы вы обшолись? Использовали orm, dbal или вообще голые массивы и запросы?

На 100 записей однозначно без доктрины) это слишком заморочно ради 100. У нас в проекте она в итоге из-за перегрузки обрасла еще всякими стратегиями на гидрации и прочим.

Хочу понять тогда область ее применения... Какой-то можете дать use case?

Помогает, например, в связке с apigility. Генерит рест на описанную сущность. Очень ускоряет разработку.

у джефри вэя был классны наброс на эту тему же) года полтора назад, он утвреждал что в динамических языках вообще всё это не надо, и приятнее читать просто код без всяких уточнений, при условии адекватного нейминга

Хочу понять тогда область ее применения... Какой-то можете дать use case?

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

орм и доктрина в частности актуальны для write модели, когда у нас естьк акие то бизнесс требования и мы должны выполнять какие то действия над сущностями, следить за их валдиностью и т.п Когда просто нужно что то прочитать, нужно дейтсовать максимально просто. Эт я так вижу

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

лично у меня нехилая часть БЛ - это расчёты на основании данных сущностей

может метод переименовать?

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

можно подумать ты их руками пишешь)

Максим, как я понял вообще каждую функцию комментит

вот в 7.4 проперти будут типизирвоанные

в последнем дайджесте говорили что будет в 8-ке)