Я лично думаю, что тенденция вообще идет в сторону отказа от JS, как от языка программирования, предназначенного для людей.
Так уж повелось, что код на JS исполняется браузерами. Быстро и хорошо исполняется. Отлично. Эта ситуация останется еще на десятки лет доминирующей.
Но заставлять живых людей писать на JS и даже придумывать целые "фреймворки" (не являющиеся таковыми) для этого?
Нет, это не магистраль. Магистраль - это судьба JS, как языка промежуточного представления кода. Как нового ассемблера.
Посмотрите, к примеру, на Symfony Live Components, библиотеку, позволяющую бэкенд-разработчику создавать сложные и "живые" интерфейсы, не написав ни строчки кода на JS вручную.
Это - и есть следующий магистральный путь. Кода мы берем настоящий язык программирования, с настоящей системой типов, пишем на нем, а уж во что оно там транслируется - стараемся не задумываться.
Между прочим, так примерно и развивается IT последние лет 50. Ничего нового.
Как же тонко и аккуратно вы обходите момент, что PHP - прекрасный язык общего назначения, занимающий порядка 90% рынка веб-разработки (один человек это сказал, да), востребованный везде и всеми и что специалистов (настоящих) по PHP ждут везде и за любые деньги.
Это же просто переводы? Без каких-либо гарантий и обязательств?
Если это платежи - где авторизация, холд и собственно списание? Где возможность опротестовать платеж, да и вообще, хоть как-то пообщаться с платежной системой?
Поставил вам минус за низкий технический уровень материала, и готов объяснить, почему.
Стоило упомянуть, что для реализации DTO чаще всего используется паттерн Value Object и указать на разницу между этими двумя понятиями.
Неплохо бы объъяснить разницу между Value Object и Entity.
Стоило рассказать, что DTO по определению является иммутабельным объектом. А из этот следует применение модификатора readonly в свойствах и/или в классе.
Не упомянут тайп-хинтинг свойств - почему?
Если мы уж говорим о валидации, то стоит акцентировать внимание на том, что Value Object (и DTO, как подкласс) не могут находиться в невалидном состоянии, иначе это нарушает смысл паттерна.
Валидация может быть как при создании объекта (в конструкторе), так и условно "внешняя"
Второй вариант валидации - более гибкий. Он позволяет задать с помощью метаданных правила и сценарии валидации.
Метаданные в современном PHP задаются через атрибуты. Нужно было бы показать пример, например из Symfony.
Для преобразования в JSON в стандартной библиотеке PHP есть интерфейс. Почему его не использовали?
Я бы посоветовал вам взять примеры сериализации таких объектов опять же из Symfony. И рассказать про метаданные, две стадии сериализации (преобразование в массив, а затем в нужный формат) и про десериализацию.
>> А что вы думаете об этой тенденции?
Я лично думаю, что тенденция вообще идет в сторону отказа от JS, как от языка программирования, предназначенного для людей.
Так уж повелось, что код на JS исполняется браузерами. Быстро и хорошо исполняется. Отлично. Эта ситуация останется еще на десятки лет доминирующей.
Но заставлять живых людей писать на JS и даже придумывать целые "фреймворки" (не являющиеся таковыми) для этого?
Нет, это не магистраль. Магистраль - это судьба JS, как языка промежуточного представления кода. Как нового ассемблера.
Посмотрите, к примеру, на Symfony Live Components, библиотеку, позволяющую бэкенд-разработчику создавать сложные и "живые" интерфейсы, не написав ни строчки кода на JS вручную.
Это - и есть следующий магистральный путь. Кода мы берем настоящий язык программирования, с настоящей системой типов, пишем на нем, а уж во что оно там транслируется - стараемся не задумываться.
Между прочим, так примерно и развивается IT последние лет 50. Ничего нового.
Придумайте уже себе вменяемый пакетный менеджер, как в других языках и экосистемах. Можно даже скопировать ))
Чем хорош PHP - на нем можно писать в таком стиле, за который уже 15 лет назад руки отрывали, а оно всё равно работает ))
Как же тонко и аккуратно вы обходите момент, что PHP - прекрасный язык общего назначения, занимающий порядка 90% рынка веб-разработки (один человек это сказал, да), востребованный везде и всеми и что специалистов (настоящих) по PHP ждут везде и за любые деньги.
Зато не забыли мертвый Руби упомянуть.
Что за комплексы у вас?
Если вы видите, что студент или выпускник использует MongoDB, то остановите его. Ему нужна помощь. Его ввели в заблуждение.Пожалуйста, ставьте плюсы статье и автору только за эту цитату, я вас прошу. Господи, наконец-то на хабре правда!
А где статья?
Но... это же не платежи, верно?
Это же просто переводы? Без каких-либо гарантий и обязательств?
Если это платежи - где авторизация, холд и собственно списание? Где возможность опротестовать платеж, да и вообще, хоть как-то пообщаться с платежной системой?
У этого - нет бесплатной. Многие по прошествии времени выкладываются бесплатно.
Даже "улучшив" публикацию, вы всё равно несете в ней какой-то малосвязный бред.
Поставил вам минус за низкий технический уровень материала, и готов объяснить, почему.
Стоило упомянуть, что для реализации DTO чаще всего используется паттерн Value Object и указать на разницу между этими двумя понятиями.
Неплохо бы объъяснить разницу между Value Object и Entity.
Стоило рассказать, что DTO по определению является иммутабельным объектом. А из этот следует применение модификатора readonly в свойствах и/или в классе.
Не упомянут тайп-хинтинг свойств - почему?
Если мы уж говорим о валидации, то стоит акцентировать внимание на том, что Value Object (и DTO, как подкласс) не могут находиться в невалидном состоянии, иначе это нарушает смысл паттерна.
Валидация может быть как при создании объекта (в конструкторе), так и условно "внешняя"
Второй вариант валидации - более гибкий. Он позволяет задать с помощью метаданных правила и сценарии валидации.
Метаданные в современном PHP задаются через атрибуты. Нужно было бы показать пример, например из Symfony.
Для преобразования в JSON в стандартной библиотеке PHP есть интерфейс. Почему его не использовали?
Я бы посоветовал вам взять примеры сериализации таких объектов опять же из Symfony. И рассказать про метаданные, две стадии сериализации (преобразование в массив, а затем в нужный формат) и про десериализацию.
и это только навскидку...
Спасибо.
Вместо глобальных переменных можно использовать статические методы какого-либо класса, как, кстати, делает Fiber.
Ты не душнишь, ты экзотику накидываешь, за что тебе большое спасибо! ))
Кирилл, я имел в виду, что в стандартной библиотеке нет готового "setInterval" или иных инструментов, чтобы отложить задачу.
А за пример спасибо, интересно.
Вы "ищете блох" в конкретном примере, утверждая, что ложку можно вырезать из полена и без рейсфедера.
Я же вам рассказываю - что такое рейсфедер и как его применять, безотносительно ложки.
Причем тут ваш пример?
Конечно есть. Представьте себе файл со списком недействительных паспортов: https://проверки.гувм.мвд.рф/upload/expired-passports/list_of_expired_passports.csv.bz2
Всего-то 500+ мегабайт CSV в архиве. Сделайте его обработку без генераторов и со считыванием всего файла в память.
Я не одним днем готовил этот текст, прошу прощения.
Слово «интерпретатор» не очень корректное, в остальном, конечно же, вы правы.
Такой вариант создает достаточно большую нагрузку, проверяя типы списка аргументов в рантайме.
Ваша правда. Включил в дайджест, потому что она обсуждалась в PHP Weekly.
Уберу.