Read models naming

[Вурдалак]

А, да, вот еще в php не хватает конструкции "public readonly".

Я бы больше хотел final properties как в Java, но в 99% (по крайней мере, в моём случае) эти фичи бы использовались одинаково.

 

[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]

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

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

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

 

[grigori]

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

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

 

[grigori]

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

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

 

[Вурдалак]

@grigori санкции — это польза, рабство — это свобода, удобство — это недостаток.

 

[grigori]

не понимаю
это аргумент против какого моего тезиса?

 

[Adelf]

Думаю, против

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

я уже говорил что для нормальной скорости рефакторинга разница есть. Да и не только рефакторинга... я юзаю Find usages несколько раз в день.

 

[grigori]

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

 

[grigori]

в питоне, раби и golang дженериков нет - в питоне только статическая проверка по комментам в mypy,
задача обеспечения полиморфизма с типизацией решается через duck typing некоторого вида, что совсем не решает задачи @Adelf

 

[Adelf]

ни в питоне, ни в раби дженериков нет - в питоне только статическая проверка по комментам в 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'ах.

 

[WMix]

@Adelf, а эту штуку разглядывал?

 

[fixxxer]

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