А вы смотрели этот репозиторий? Это проект к php-fig имеет довольно посредственное отношение. Автор этого проекта по сути один человек dereuromark и он меняет многие устоявшиеся нормы, в частности:
Code MUST use 1 tab for indenting, not spaces. Spaces are for alignment and separation of words/text, only tabs are by definition valid indentation characters.
Я не думаю, что стоит рассматривать этот проект всерьез или у вас есть другая информация?
Я безусловно согласен с тем, что использование strict mode по умолчанию является хорошей практикой, но в данном случае и без него код будет работать корректно.
И вы забыли еще об одной детали:
If the requested component doesn't exist within the given URL, NULL will be returned.
В изначальном коде не выполнялась проверка на корректность URL и я полагаю, что валидация URL была сделана где-то ранее. То есть, задача этой строчки кода только проверить допустимый домен в URL, а не проверять корректность URL.
И здесь неважен strict mode и false который может вернуть функция parse_url(). В этом примере in_array()всегда будет возвращать false для таких случаев.
А есть методики идентификации краулеров и ботов?
Ну то есть понятно, что запросы без User-Agent или с корявым User-Agent фальшивка. Запросы без кук вероятно фальшывые. Большое количество запросов с одного IP. Частые запросы с одного IP. Запросы с одного IP с одинаковым интервалом. Запросы из публичного списка прокси. Запросы из Tor exit nodes.
Я об этом и говорил. Мы не создаём сущность одну на весь проект. В каждом контексте свои ограничения. Но если мы не отразим в коде ограничения конкретного контекста, то получим сущность нарушающую инварианты.
Если говорить о предметной области, то это DDD и класс обязан быть построен на свойствах объекта предметной области. И если предметная область говорит нам о том, что есть Напиток и Кофе, и наша предметная область в конкретном ограниченном контексте говорит, что Кофе это частный случай Напитка, то в коде мы обязаны отразить это наследование.
Лучше выделить более общий подтип для обеих фигур.
Несмотря на кажущееся сходство квадрата и прямоугольника, они разные. Квадрат имеет много общего с ромбом, а прямоугольник с параллелограммом, но они не являются подтипом. Квадрат, прямоугольник, ромб и параллелограмм — это отдельные фигуры со своими собственными свойствами, хотя и схожими.
Я об этом и говорю, что необходимость объявления свойства как nullable в явном виде при переходе на PHP 7.4 не очевидна.
Не смотря на то, что я изучал вопрос type hunting свойств класса, я упустил из виду эту особенность. Безусловно это полностью моя вина и невнимательность, но я не вижу, что бы кто либо делал акцент на этой особенности. И в RFC этот нюанс описан вскользь и при беглом осмотре его легко упустить. Отсюда я предполагаю, что с этой проблемой могу столкнуться не только я, а ещё очень многие разработчики которые не слишком внимательно следят за всеми фичами в PHP. Хотя возможно мои домыслы надуманы и ни какой проблемы нет. Время покажет.
Тут скорее не "рассчитывает на дефолтный null без его явного задания", а "не рассчитывает на Fatal error без его явного задания".
Проблема не в том, что логика приложение может быть построена на том, что значение по умолчанию null. Проблема в том, что обращение к свойству может быть и не в биснес логике, а где-то на низкоуровневых слоях в сторонних библиотеках типа форм, движка БД, шаблонгизатора и т.д. где скорее важно есть ли значение у свойства или нет.
К примеру, ты можешь не ожидать, что этот шаблон может падать с Fatal error у некоторых пользователей:
Возраст пользователя {{ app.user.age }}
Или форма после отправки может падать с Fatal error если пользователь заполнил не все поля формы или подменил какие-то поля формы.
Тут согласен. Наверное так и правда правильней, но меня смутило то, что переход на type hinting в свойствах класса будет не так очевиден как хотелось бы. Боюсь многие наступят на эти грабли.
Проблема известная и довольно старая. Тоже от неё страдаем. https://github.com/docker/for-win/issues/188
WSL 2 уже зарелизили, но мне ещё не довелось опробовать. https://devblogs.microsoft.com/commandline/wsl-2-is-now-available-in-windows-insiders/
А вы смотрели этот репозиторий? Это проект к php-fig имеет довольно посредственное отношение. Автор этого проекта по сути один человек dereuromark и он меняет многие устоявшиеся нормы, в частности:
Я не думаю, что стоит рассматривать этот проект всерьез или у вас есть другая информация?
А в чем проблема импортировать тикеты из GitHub в GitLab с сохранением номеров тикетов? Посмотрите на туже Doctrine.
Я безусловно согласен с тем, что использование strict mode по умолчанию является хорошей практикой, но в данном случае и без него код будет работать корректно.
И вы забыли еще об одной детали:
В изначальном коде не выполнялась проверка на корректность URL и я полагаю, что валидация URL была сделана где-то ранее. То есть, задача этой строчки кода только проверить допустимый домен в URL, а не проверять корректность URL.
И здесь неважен strict mode и false который может вернуть функция
parse_url(). В этом примереin_array()всегда будет возвращать false для таких случаев.В PHP это делается так
Точка без звёздочки заменяет только один символ. Как сказали выше, добавление
^$решит проблему.До недавнего времени, он был по умолчанию включён в php-cs-fixer и Style CI. Сейчас уже исправились.
Есть лайфхак Yoda conditions. Он помогает избежать ошибок в операциях сравнения, хотя мне такой стиль записи условий не нравится.
А есть методики идентификации краулеров и ботов?
Ну то есть понятно, что запросы без User-Agent или с корявым User-Agent фальшивка. Запросы без кук вероятно фальшывые. Большое количество запросов с одного IP. Частые запросы с одного IP. Запросы с одного IP с одинаковым интервалом. Запросы из публичного списка прокси. Запросы из Tor exit nodes.
Какие ещё есть методы?
Я об этом и говорил. Мы не создаём сущность одну на весь проект. В каждом контексте свои ограничения. Но если мы не отразим в коде ограничения конкретного контекста, то получим сущность нарушающую инварианты.
А я бы не добавлял)))
Безусловно, DDD не единственный способ разработки и не панацея во многих кейсах, но он облегчает разработку, чтение, сопровождение и рефакторинг кода.
Если говорить о предметной области, то это DDD и класс обязан быть построен на свойствах объекта предметной области. И если предметная область говорит нам о том, что есть Напиток и Кофе, и наша предметная область в конкретном ограниченном контексте говорит, что Кофе это частный случай Напитка, то в коде мы обязаны отразить это наследование.
Лучше выделить более общий подтип для обеих фигур.
Несмотря на кажущееся сходство квадрата и прямоугольника, они разные. Квадрат имеет много общего с ромбом, а прямоугольник с параллелограммом, но они не являются подтипом. Квадрат, прямоугольник, ромб и параллелограмм — это отдельные фигуры со своими собственными свойствами, хотя и схожими.
Подробнее здесь.
Я об этом и говорю, что необходимость объявления свойства как nullable в явном виде при переходе на PHP 7.4 не очевидна.
Не смотря на то, что я изучал вопрос type hunting свойств класса, я упустил из виду эту особенность. Безусловно это полностью моя вина и невнимательность, но я не вижу, что бы кто либо делал акцент на этой особенности. И в RFC этот нюанс описан вскользь и при беглом осмотре его легко упустить. Отсюда я предполагаю, что с этой проблемой могу столкнуться не только я, а ещё очень многие разработчики которые не слишком внимательно следят за всеми фичами в PHP. Хотя возможно мои домыслы надуманы и ни какой проблемы нет. Время покажет.
Точнее нет. После отправки формы скорей можно схлопотать TypeError, а Fatal error скорей при рендере или валидации формы.
Тут скорее не "рассчитывает на дефолтный null без его явного задания", а "не рассчитывает на Fatal error без его явного задания".
Проблема не в том, что логика приложение может быть построена на том, что значение по умолчанию null. Проблема в том, что обращение к свойству может быть и не в биснес логике, а где-то на низкоуровневых слоях в сторонних библиотеках типа форм, движка БД, шаблонгизатора и т.д. где скорее важно есть ли значение у свойства или нет.
К примеру, ты можешь не ожидать, что этот шаблон может падать с Fatal error у некоторых пользователей:
Или форма после отправки может падать с Fatal error если пользователь заполнил не все поля формы или подменил какие-то поля формы.
Тут согласен. Наверное так и правда правильней, но меня смутило то, что переход на type hinting в свойствах класса будет не так очевиден как хотелось бы. Боюсь многие наступят на эти грабли.
Ну, то есть понятно, что код мигрирует на PHP 7.4 по другому.
Но мне кажется это как-то не так должно быть.