Pull to refresh

Comments 39

Всё-таки здесь используется слово «стандарт».
UFO just landed and posted this here
Прикиньте RFC тоже не стандарт ;)
Блин, снова вместо древних стандартных set/unset имеем незнакомые with/without :(
По смыслу больше подходит для такого стиля.
Запрос->c_заголовком(1)->без_заголовка(2)->отправить();
В то время, как код с set и unset представляется как
Запрос->установить_заголовок(1);
Запрос->убрать_заголовок(2);
Запрос->отправить();
в аннотации к Message интерфейсу написано:
> Messages are considered immutable
то есть сообщение нельзя менять, поэтому как уже говорил ilyaplot set/unset тут не подходит — эти методы создают новое сообщение
я отвечал на конкретную ветку про set/unset, почему сообщение сделано неизменяемым это уже другой вопрос
к этому стандарту есть «пояснительная записка» в которой отражены мысли по этому поводу:
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);
}
Вы очень вовремя. Если честно, я не все понял из поста после того, как работал с кодом весь день.
Скажите, а насколько это правильно использовать 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 надеемся и верим…
Если вам нужно просто предоставить API для HTTP-запросов — за что пинать? А вот если вам, например, нужны вебсокеты или ещё что-нибудь выходящее за рамки отлаженных кейсов работы с PHP — тогда лучше воздержаться. Есть всякие штуки типа ReactPHP, но всё же это пока слабо распространено.
Сколько сталкиваюсь с этим PSR-7 — вроде полезно должно быть, но не пойму в чем отличие от того же Symfony\HttpFoundation кроме «стандартизации»
Ну раз уж в PHP-FIG собрались ребята знакомые не только с Symfony, то для этого стандарта, по идее, они выбрали лучшее, что было в уже существующих реализациях.
смысл стандартов как раз в стандартизации. Тот же HttpFoundation и HttpKernel будет раздроблен на более мелкие компоненты.
Я как-то не понял этой радости от «объект-значение». В примерах статьи чаще всего не нужна новая копия. Как-то неприятно смотреть, что в процессе изменения нескольих свойств «рождаются» и тут же «умирают» несколько объектов. И хочется спросить, а чем clone не удовлетворил?
Вот эти два пункта, которые Вы оформили в виде задач, связаны. В первом случае мы создаём новый объект без этого свойства — without. Во втором случае мы удаляём свойство из объекта — unset.
Изначально хотел всё в одну запихнуть, но потом подумал что лучше раздельно… Или все-таки надо было в одну?
Если честно, то не совсем я понял этот ответ. Основной посыл, который я понял: если изменять состояние, то может случиться что-то страшное.
Имхо, но PSR-7 не лучший стандарт PSR.

Он предоставляет интерфейсы, которые должны реализовать фреймворки.
Т.е. ещё одна зависимость в композере от пакета 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.
Вдруг кто не в курсе:

Некоторые клиенты выдают ошибку при попытке передать в строке 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?

Only those users with full accounts are able to leave comments. Log in, please.

Articles