Read models naming

grigori

( ͡° ͜ʖ ͡°)
Команда форума
В typescript совсем не так же, как в golang, и оба варианта не совсем duck typing, но это уже совсем оффтопик.
отвлекаясь от терминологии, речь о том, что для соответствия интерфейсу объекту нужно реализовать его методы,
а в golang можно задать и структуру данных https://tour.golang.org/methods/11

что касается терминологии, в документации по TypeScript прямо написано, что он реализует "duck typing", а в golang - про implicit implementation

главное - в этих языках есть выделенный этап компиляции, который не ограничен по скорости и памяти

Happy refactoring, bitches.
я подразумеваю наличие PHPDoc

Постоянно надо, когда работаешь с коллекциями в том или ином виде. PhpStorm-овская поддержка PhpDoc вида @return Foo[]|Collection, конечно, выручает, но все же это не на том уровне.
собственно, вопрос сводится к тому, насколько часто ты работаешь с такими коллекциями, при работе с которыми нужно помнить структуру в разных местах, а @return Foo[]|Collection не хватает
 
Последнее редактирование:

Adelf

Administrator
Команда форума
Засорили тему :) Я тут хотел вопрос задать. Немного в догонку. А как юнит-тестить write модели? Результат проверять как? анализируя только events и все?

собственно, вопрос сводится к тому, насколько часто ты работаешь с такими коллекциями, при работе с которыми нужно помнить структуру в разных местах, а @return Foo[]|Collection не хватает
Ну вот в С# прям сильно удобно работать с коллекциями. Linq. В яве тоже стримы ввели. Не просто так. Частенько такое пригождается. Мы просто привыкли к foreach. Но и там надо кастить переменные к типу. тут важно не столько "помнить структуру", а для какого-то поля - возможность быстро найти ВСЕ места где оно юзается. Сильно ускоряет рефакторинги. А с массивами везде приходится phpDoc или типизировать аргументы колбэков. Не совсем удобно.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Засорили тему :) Я тут хотел вопрос задать. Немного в догонку. А как юнит-тестить write модели? Результат проверять как? анализируя только events и все?
интеграционный тест сделай с предварительной инициализацией базы, и не мучайся
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
ты раздели вопросы: foreach, кастинг к типу, структура, рефакторинг
для читаемости и рефакторинга нет большой разницы указывать ли типизацию в коде или в PHPDoc, если есть желание ее указывать,
другое дело, что ты не указываешь, когда можно этого не делать, но защищать программиста от самого себя - это так себе цель

знаешь, к чему привела строгая типизация в джаве? кодеры не проверяют работу своего кода, скомпилировалось - значит, правильно
 
Последнее редактирование:

grigori

( ͡° ͜ʖ ͡°)
Команда форума
не понимаю
это аргумент против какого моего тезиса?
 

Adelf

Administrator
Команда форума
Думаю, против :)
для читаемости и рефакторинга нет большой разницы указывать ли типизацию в коде или в PHPDoc, если есть желание ее указывать,
я уже говорил что для нормальной скорости рефакторинга разница есть. Да и не только рефакторинга... я юзаю Find usages несколько раз в день.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
нет, я не оспариваю потребность в типизации элементов коллекций - это желание очевидное, я думаю о других вопросах:
* в каких именно ситуациях нельзя компенсировать недостаток с помощью PHPDoc
* нет ли в этом поиска идеала "Если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмича"
* как решить задачу
* есть ли у дженериков цена компиляции
 
Последнее редактирование:

grigori

( ͡° ͜ʖ ͡°)
Команда форума
в питоне, раби и golang дженериков нет - в питоне только статическая проверка по комментам в mypy,
задача обеспечения полиморфизма с типизацией решается через duck typing некоторого вида, что совсем не решает задачи @Adelf
 
Последнее редактирование:

Adelf

Administrator
Команда форума
ни в питоне, ни в раби дженериков нет - в питоне только статическая проверка по комментам в mypy,
да там даже интерфейсов нет. да я не мечтаю даже о нормальных дженериках в PHP. Чую я, это весьма непросто для скриптовых языков. где-то наверняка будут просадки по производительности. все эти ко и контра-вариантности...
Хотя... с jit-компиляцией всякой... но все равно работы там туча туч
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
в общем, как писал Льюис Керрол,
план был замечательный — такой простой и ясный. Одно только плохо: Алиса не имела ни малейшего представления о том, как все это осуществить
 

Вурдалак

Продвинутый новичок
А как юнит-тестить write модели? Результат проверять как? анализируя только events и все?
Если у тебя event sourced модель (не в плане персистности, а в плане внутренного устройства), то этого должно быть достаточно.

Но если ты используешь, например, Behat, то там скорее всего сценарии будут совпадать с теми, что ты описываешь в unit-тесте и необходимость в точечном unit-тесте как-то отпадает. То есть, можно действительно заодно проверить взаимодействие с инфраструктурой.
 

fixxxer

К.О.
Партнер клуба
Но если ты используешь, например, Behat, то там скорее всего сценарии будут совпадать с теми, что ты описываешь в unit-тесте и необходимость в точечном unit-тесте как-то отпадает. То есть, можно действительно заодно проверить взаимодействие с инфраструктурой.
А получается с BDD only следовать принципу test first? Сценарии-то разной сложности бывают, могут затрагивать не только одну write model.
 

Вурдалак

Продвинутый новичок
А получается с BDD only следовать принципу test first? Сценарии-то разной сложности бывают, могут затрагивать не только одну write model.
В BDD как раз нет «test first», там «specification first», а этому следовать получается уже более-менее.
Ведь тут главное — раскрыть команды и события, причём совсем необязательно писать сначала сценарии, там есть блоки свободного текста, где ты можешь писать вообще что угодно. Затрагивать несколько сущностей, конечно, может, но это не мешает описать логику и сценарии сначала для одной. Да и по опыту спецификации в основном вертятся вокруг одной сущности.

С PHPUnit у меня всегда проблема в том, что там больше всё-таки тест: там нужно использовать ещё несуществующий класс, методы и события, либо бегать туда-сюда, что неудобно. Я ещё толком не знаю как назвать команды и события, буду сначала их создавать, чтобы описать в PHPUnit-тесте, а потом тут же переписывать, потому что понял, что они неудачные. В результате я просто буду писать код в модели, чтобы понять, норм ли это, и в итоге всё сводится к «test last».

Я не против PHPUnit, и использую его, но TDD нет. Behat же приучает именно к другому типу разработки и тестирование с ним становится лишь следствием, что уже выглядит естественно. TDD же выглядит неестественно. И если ты уже написал спецификацию на Behat, то уже в конце тебе скорее всего не захочется ещё писать тест в PHPUnit, потому что все эти кейсы скорее всего были зафиксированы в спецификации, а это значит, что тесты лучше будет писать в Behat context'ах.
 
Последнее редактирование:

fixxxer

К.О.
Партнер клуба
@WMix, меня сразу смущает "naming-convention based". С такими искусственными ограничениями часто приходится именовать вещи не так, как следовало бы, только чтобы уложиться в эти самые conventions. Да и такая магия, явно основанная на __call(), затрудняет рефакторинг.
 
Сверху