Комментарии 39
Стандарт PSR-7 успешно завершён.Да не стандарт это. Просто рекомендация (PHP Standard Recommendation).
Всё-таки здесь используется слово «стандарт».
НЛО прилетело и опубликовало эту надпись здесь
Прикиньте RFC тоже не стандарт ;)
Блин, снова вместо древних стандартных set/unset имеем незнакомые with/without :(
По смыслу больше подходит для такого стиля.
Запрос->c_заголовком(1)->без_заголовка(2)->отправить();
В то время, как код с set и unset представляется как
Запрос->установить_заголовок(1);
Запрос->убрать_заголовок(2);
Запрос->отправить();
Запрос->c_заголовком(1)->без_заголовка(2)->отправить();
В то время, как код с set и unset представляется как
Запрос->установить_заголовок(1);
Запрос->убрать_заголовок(2);
Запрос->отправить();
Спросил как мог github.com/php-fig/fig-standards/issues/431 (может кто чего добавит)
в аннотации к Message интерфейсу написано:
> Messages are considered immutable
то есть сообщение нельзя менять, поэтому как уже говорил ilyaplot set/unset тут не подходит — эти методы создают новое сообщение
> Messages are considered immutable
то есть сообщение нельзя менять, поэтому как уже говорил ilyaplot set/unset тут не подходит — эти методы создают новое сообщение
Почему? sectus чуть ниже очень правильно напомнил про clone и множество безымянных объектов.
я отвечал на конкретную ветку про set/unset, почему сообщение сделано неизменяемым это уже другой вопрос
к этому стандарту есть «пояснительная записка» в которой отражены мысли по этому поводу:
github.com/php-fig/fig-standards/blob/master/proposed/http-message-meta.md#why-value-objects
к этому стандарту есть «пояснительная записка» в которой отражены мысли по этому поводу:
github.com/php-fig/fig-standards/blob/master/proposed/http-message-meta.md#why-value-objects
Тоже самое можно реализовать с использование свойства readonly, которое позволит избавиться от промежуточных объектов и заблокирует изменения после отправки (хотя еще вопрос насколько это нужно).
не я автор этого стандарта, из документа вытекает такой смысл:
Интерфейс внутри сервера для работы с запросом будет подразумевать явное его изменение, таким образом избавляются от случайных изменений по сути глобального объекта, также благодаря этому приложение может отреагировать на это изменение, именно как цельного набора значений, а не отдельных свойств
Интерфейс внутри сервера для работы с запросом будет подразумевать явное его изменение, таким образом избавляются от случайных изменений по сути глобального объекта, также благодаря этому приложение может отреагировать на это изменение, именно как цельного набора значений, а не отдельных свойств
Угу, и там же говориться что в большинстве популярных библиотек сообщения mutable и много кому нужно их менять — нахрена такой «стандарт»? Это даже не говоря о том что без цепочек новый объект весьма проблематично создать (а оно нужно если те же заголовки добавляются в зависимости от внешних условий)
Вы забываете про то что mutable объекты плохо согласуются с такими вещями как многопоточность и т.д. VO тут подходит лучше. Все же этот стандарт будут применять при реализации мидлвэров, серверов и т.д. и сценарий при котором мутабл объекты это плохо более чем реальны.
Да и вообще, можете привести пример в коде когда вас это парит?
Да и вообще, можете привести пример в коде когда вас это парит?
Мне кажется это вы забыли что в PHP многопоточности вообще НЕТ и маловероятно что она когда нибудь будет. + еще есть java/c# и много других языков где она есть, но проблем с изменяемыми объектами нет (есть сложности и особенности, но не проблемы).
Запросто:
$myObjectWithSuperName = new Object();
if ($veryLongSettingName1 == 1) {
$myObjectWithSuperName = $myObjectWithSuperName->with(1);
}
if ($veryLongSettingName2 == 2) {
$myObjectWithSuperName = $myObjectWithSuperName->with(2);
}
Запросто:
$myObjectWithSuperName = new Object();
if ($veryLongSettingName1 == 1) {
$myObjectWithSuperName = $myObjectWithSuperName->with(1);
}
if ($veryLongSettingName2 == 2) {
$myObjectWithSuperName = $myObjectWithSuperName->with(2);
}
Вы очень вовремя. Если честно, я не все понял из поста после того, как работал с кодом весь день.
Скажите, а насколько это правильно использовать PHP для API сервера? Не будут ли меня пинать, когда узнают, что мой сервер работает на PHP?
Скажите, а насколько это правильно использовать PHP для API сервера? Не будут ли меня пинать, когда узнают, что мой сервер работает на PHP?
Полагаю, что если качество работы сервера не будет вызывать нареканий, то никто вас «пинать» не будет.
Я просто привык к тому, что все не любят php программистов. Правда, ни разу никто не объяснил причину такого отношения :)
ну объективно надо разделять нелюбовь к языку php и к программистам на php. И то и то имеет место быть, но имеет разные причины.
PHP популярный язык программирования с низким порогом входа, поэтому и программистов на нем гораздо больше чем например на C, и сосредоточенны они достаточно кучно — так или иначе рядом с вебом, и даже если % хороших программистов не зависит от ЯП, то в абсолютных цифрах % оставшихся все равно больше (а если взять порог входа, то и сам процент не в пользу php).
У самого языка/реализации тоже есть проблемы, кроме разнородных неймингов стандартной либы, не очевидных поведений и достаточной забаговановасти ядра (где-то в 5.5-5.6 мне более менее перестали попадаться всякие неожиданные сегфолты, которые без ковыряния в коде ядра, которое просто жутко как написано, не починишь) много ограничений дает «PHP создан, чтобы умирать» — да можно писать демоны и на php но это будут скорее какие-то воркеры, чем сервер для обработки клиентских запросов, потомучно в PHP все работает исходя из этого постулата, ни GC ни стандартные библиотеки, ни уж тем более сторонние, не создавались для того чтобы обслужить больше 1 запроса. А уж отсутсвие JIT в 2015 году это я даже не знаю как назвать. (да какой JIT даже отсутствие встроенного кешера байт-кода до 5.5)
Да и от языка скриптования шаблонов он начал отходить относительно недавно, а порядок в нем начали наводить так вообще не больше 2-3 лет назад.
Очень хороший пинок дали Composer и Symfony Components, а также появление альтернативных реализация рантайма.
В общем ждем PHP 7 надеемся и верим…
PHP популярный язык программирования с низким порогом входа, поэтому и программистов на нем гораздо больше чем например на C, и сосредоточенны они достаточно кучно — так или иначе рядом с вебом, и даже если % хороших программистов не зависит от ЯП, то в абсолютных цифрах % оставшихся все равно больше (а если взять порог входа, то и сам процент не в пользу php).
У самого языка/реализации тоже есть проблемы, кроме разнородных неймингов стандартной либы, не очевидных поведений и достаточной забаговановасти ядра (где-то в 5.5-5.6 мне более менее перестали попадаться всякие неожиданные сегфолты, которые без ковыряния в коде ядра, которое просто жутко как написано, не починишь) много ограничений дает «PHP создан, чтобы умирать» — да можно писать демоны и на php но это будут скорее какие-то воркеры, чем сервер для обработки клиентских запросов, потомучно в PHP все работает исходя из этого постулата, ни GC ни стандартные библиотеки, ни уж тем более сторонние, не создавались для того чтобы обслужить больше 1 запроса. А уж отсутсвие JIT в 2015 году это я даже не знаю как назвать. (да какой JIT даже отсутствие встроенного кешера байт-кода до 5.5)
Да и от языка скриптования шаблонов он начал отходить относительно недавно, а порядок в нем начали наводить так вообще не больше 2-3 лет назад.
Очень хороший пинок дали Composer и Symfony Components, а также появление альтернативных реализация рантайма.
В общем ждем PHP 7 надеемся и верим…
Если вам нужно просто предоставить API для HTTP-запросов — за что пинать? А вот если вам, например, нужны вебсокеты или ещё что-нибудь выходящее за рамки отлаженных кейсов работы с PHP — тогда лучше воздержаться. Есть всякие штуки типа ReactPHP, но всё же это пока слабо распространено.
Сколько сталкиваюсь с этим PSR-7 — вроде полезно должно быть, но не пойму в чем отличие от того же Symfony\HttpFoundation кроме «стандартизации»
Я как-то не понял этой радости от «объект-значение». В примерах статьи чаще всего не нужна новая копия. Как-то неприятно смотреть, что в процессе изменения нескольих свойств «рождаются» и тут же «умирают» несколько объектов. И хочется спросить, а чем clone не удовлетворил?
Спросил как мог github.com/php-fig/fig-standards/issues/432 (может кто чего добавит)
Возможно здесь будет ответ на ваш вопрос.
Имхо, но PSR-7 не лучший стандарт PSR.
Он предоставляет интерфейсы, которые должны реализовать фреймворки.
Т.е. ещё одна зависимость в композере от пакета php-fig/http-message
Итак уже в папке vendor множество всяких пакетов… И тут будет ещё один.
Для чего это? Чтобы облегчить перевод приложения из одного фреймворка в другой?
Фреймворки должны реализовать группу интерфейсов PSR-7, но никто не мешает авторам фреймворков добавить собственные методы. Это не нарушает принципы ООП. А эти методы могут быть очень полезными.
Т.е. встаёт выбор, использовать интерфейс PSR-7, и иметь независимость от фреймворка.
Или использовать интерфейс фреймворка(который также реализует PSR-7), но. получить зависимость от фреймворка и удобные методы.
Я выберу второе.
Имхо, единственный и главный плюс этого стандартна, когда программируешь на одном фрейморке, потом вдруг понадобилось использовать другой — а ты уже знаешь, как обращаться с http компонентом.
Но тут IDE намного больше пользы принесет.
Серьёзно, в чём плюс этого PSR-7?
Он предоставляет интерфейсы, которые должны реализовать фреймворки.
Т.е. ещё одна зависимость в композере от пакета php-fig/http-message
Итак уже в папке vendor множество всяких пакетов… И тут будет ещё один.
Для чего это? Чтобы облегчить перевод приложения из одного фреймворка в другой?
Фреймворки должны реализовать группу интерфейсов PSR-7, но никто не мешает авторам фреймворков добавить собственные методы. Это не нарушает принципы ООП. А эти методы могут быть очень полезными.
Т.е. встаёт выбор, использовать интерфейс PSR-7, и иметь независимость от фреймворка.
Или использовать интерфейс фреймворка(который также реализует PSR-7), но. получить зависимость от фреймворка и удобные методы.
Я выберу второе.
Имхо, единственный и главный плюс этого стандартна, когда программируешь на одном фрейморке, потом вдруг понадобилось использовать другой — а ты уже знаешь, как обращаться с http компонентом.
Но тут IDE намного больше пользы принесет.
Серьёзно, в чём плюс этого PSR-7?
Плюс? Ну как я вижу, возможность создавать PSR-7 совместимые мидлвары (авторизация, CORS, кеширование, много чего) и сервера (ReactPHP http сервер какой-нибудь). Опять же вас никто не принуждает использовать этот стандарт.
Абсолютно аналогична необходимость этого psr к тому что о логгировании. Сейчас есть кучка пакетов, все работают с psr-log. И не нужно задумываться, как и что нужно сделать, чтобы _____ (новая либа, нужная в проект), начала писать логи своей активности прямо сейчас. Ровно также и с http.
Вы, видимо, забываете, что из php не только обрабатываются входящие запросы, но и посылаются исходящие. Скорее всего guzzle и buzz реализуют эти интерфейсы, и тогда разработчики оберток над api будут требовать не guzzle/buzz/curl, а php-fig/http-message.
Вы, видимо, забываете, что из php не только обрабатываются входящие запросы, но и посылаются исходящие. Скорее всего guzzle и buzz реализуют эти интерфейсы, и тогда разработчики оберток над api будут требовать не guzzle/buzz/curl, а php-fig/http-message.
Вдруг кто не в курсе:
Некоторые клиенты выдают ошибку при попытке передать в строке GET-запроса массив. Чтобы этого не случилось, нужно квадратные скобки урленкодить ( [ — %5B и ] — %5D)
Некоторые клиенты выдают ошибку при попытке передать в строке GET-запроса массив. Чтобы этого не случилось, нужно квадратные скобки урленкодить ( [ — %5B и ] — %5D)
Извиняюсь за некропостинг, просто только сейчас стал смотреть на PSR > 4, и вот стало мне любопытно — а в чем смысл конкретно этого PSR при еще живом то RFC 2616?
ну попробуйте ответить на вопрос в чем смысл RFC 2616, и в чем заключается задача PSR-7.
Смысл RFC 2616 в описании HTTP-протокола, PSR-7 — по факту тоже самое, только применительно к PHP. Поправьте меня, если я ошибаюсь. Потому и спрашиваю, что не понял их различия существенного и смысла создавать по этому поводу отдельный документ. Если кто объяснит мне, тупому, буду премного благодарен. Серьезно. Это не сарказм был.
смысл PSR-7 — предоставление API для работы с HTTP запросами и ответами. API для формирования HTTP сообщений, API для http стримиинга и т.д.
То есть смысл в стандартизации http клиентов и серверов с точки зрения API, дабы иметь возможность делать мидлвары и прочие вещи (PSR-15). примерно та же суть была у symfony/http kernel.
Ну это уже как по мне, дно стандартизировать такие вещи. Давайте еще стандартизируем вывод ответов в браузер. Че? Тоже нетривиальная задача. :D
То есть не надо стандартизировать абстракцию от SAPI? Инверсию управления придумали дураки? Никому не нужно иметь возможность реализации своих надстроек для оптимизации приложения (php-pm, spiral/roadrunner, php-rpm) и иметь возможность за счет "стандарта" интегрировать свое приложение в любую из этих инфраструктурных штук?
Да, дно стандарт… нинужон. Как и PSR-3, кому надо стандартизировать логгер? или PSR-11, вообще бесполезная штука. А от PSR-1 меня подбамбивает по дикому периодически… а сырой и недоработанный PSR-4?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PSR-7 в примерах