KS
да я расширил, не меняя логику старого функционала) помоему контекст и так понятен, что будет проверять все аргументы)
Size: a a a
2021 July 15
KS
OK
Сие чудо выглядит слабо полезным, если честно.
На мой взгляд, если и делать, то добавляя новый HasAll() как сказали выше, не трогая текущее апи.
На мой взгляд, если и делать, то добавляя новый HasAll() как сказали выше, не трогая текущее апи.
KS
а че дизлайкнул то?)
KS
можно аргументы?)
AK
Single responsibilty
KS
в плане не пойму чем будет лучше новый метод
СВ
потому что это похоже на историю с is_granted() с массивом ролей, где точно не ясно, как будет работать в режиме and или or
KS
это же параметрбаг, принимает параметры из запроса, зачем вообще на or проверять?)
MM
Вы работу не ищите? Нам нужны адекватные разработчики хD
VK
ну спрашивать замудреное апи фреймворка или либы на собесе это ж дичь)
VK
очевидно что интервьювер лопух
KS
так я и не наршаю это своими изменениями, у этого метода своя ответственность: проверить наличие параметра по ключу, добавив несколько аргументов, он проверит все ключи
OK
В вендорных штуках код добавить всегда проще, чем менять текущий. Потому что BC, дока и прочее(если это паблик апи какое-то).
Вот, например твои изменения меняют сигнатуру метода, теперь туда можно инт передать или еще чего.
Вот, например твои изменения меняют сигнатуру метода, теперь туда можно инт передать или еще чего.
KS
Ну тут ты прав, согласен, надо подумать о строгой типизации
OK
Плюс еще куча анрилейтед мусора с \. Такие фиксы лучше делать отдельным пр, чтобы не усложнять жизнь ревьюверам.
✨
в has - типизацию?
KS
с этим согласен
KS
хотел пиплайн починить
OK
Ну и про то, что теперь неочевидно семантически что метод делает без ныряния в код: AND или OR уже выше написали.