PSR Стандарты

    PHP-FIG

    PSR — Чуть больше, чем стиль оформления кода.

    Как показала практика, многие PHP-разработчики знакомы с аббревиатурой PSR. Однако большинство все еще ограничены знанием, что PSR это стандарт оформления кода.

    Ребята из PHP-FIG (PHP Framework Interop Group), группа концепций совместимости PHP, которые занимаются развитием PSR (PHP Standards Recommendations) шагнули далеко вперед. Поэтому давайте разберемся, что из себя представляет PSR…


    Небольшая предыстория, которая вдохновила меня на написание этой статьи.
    За последние полгода мне пришлось провести множество собеседований на позицию Middle PHP-Developer.

    Один из вопросов, который я задавал всем кандидатам, был:- «Знаете ли Вы, что такое PSR

    code style

    Как оказалось, практически всем кандидатам была знакома эта аббревиатура. Однако пытаясь рассказать подробнее, почти все разработчики указывали в основном на то, что это стандарт оформления кода (code style). Только некоторые упоминали про PSR-4 автозагрузку (использует Composer) и PSR-3 Logger Interface (в сети очень много однородных статей про PSR-0-1-2-3-4).

    Мне кажется это весьма странным, так как термин PSR существует достаточно давно (уже более 10 лет) и каждый год набирает все большую популярность. Поэтому, думаю, будет неплохо собрать все в кучу и сделать обзор PSR стандартов.


    PHP-FIG и PSR


    PHP-FIG (PHP Framework Interop Group) — организованная в 2009 году группа разработчиков, основная идея которой находить способы совместной работы, выделяя общие концепции в разработке проектов на PHP.

    Проще говоря, ребята стараются выделить что-то общее между различными проектами на разных фреймворках и сформировать некие стандарты (рекомендации) для дальнейшего периспользования.

    Участники PHP-FIG
    ReactPHP, Composer, Laminas Project (переименованный Zend Framework), Yii framework, CakePHP, Slim, Joomla, Magento, Drupal, phpBB, phpDocumentor и другие.

    PSR (PHP Standards Recommendations) — описывает общие концепции, которые уже были проверены и отработаны. Вероятно при создании PSR, группа PHP-FIG вдохновлялась Java Community Process, а первый стандарт был принят в 2010 году.

    Список PSR стандартов расширяется новыми, а сами стандарты делятся на категории:
    Автозагрузка, Интерфейсы, HTTP и Стиль кодирования,
    каждому из которых присваивается определенный статус:
    Принят, Устаревший, Черновик и Заброшенный.

    Далее мы рассмотрим принятые PSR стандарты по категориям:

    Автозагрузка


    Composer

    Разработчики, которые "недолго" работают с PHP, вероятно не знакомы с проблемами импорта классов, ведь есть пространства имен, а сейчас вообще трудно представить проект без менеджера зависимостей Composer, которой решает все вопросы с автозагрузкой классов.

    Однако так было не всегда, пространства имен появились только в PHP 5.3 (это был 2009 год), а первый релиз Composer состоялся в марте 2012 года. Но вот сам PHP существует гораздо дольше, как Personal Home Page с 1995 года и как Hypertext Preprocessor с 1998 года, однако только PHP 5 включает "полноценную объектную модель", релиз которого был в июле 2004 года. Бородатым разработчикам того времени приходилось как-то сражаться со всеми возникшими проблемами при импорте классов.

    Не самый плохой пример импорта классов на PHP 14-ти летней давности:
    Пример кода
    class MyLib {
        private $CI;
        public function __construct()
        {
            $this->CI = &get_instance();
    
            $this->CI->load->library('encrypt');
            $this->CI->load->library('session');
            $this->CI->load->library('url');
    
            $this->CI->load->helper('captcha');
            $this->CI->load->helper('cookie');
            $this->CI->load->helper('email');
        }
        ...
    }

    (Напишите в комментариях, если узнали где использовался данный подход).

    • PSR-0 — Autoloading Standard Устарел
      После релиза пространства имен в 2009 году, в 2010 году был опубликован первый стандарт, который стал революцией в решении проблем автозагрузки классов и стал первым шагом на пути объединения фреймворков — наличие общей структуры директорий.
      Пример реализации
    • PSR-4 — Autoloading Standard
      Прогресс не стоит на месте и в конце 2013 года PHP-FIG публикуют новый стандарт автозагрузки классов. Он может использоваться в дополнение к PSR-0, а также любой другой спецификации автозагрузки. Стандарт также описывает, где размещать файлы, которые будут автоматически загружаться в соответствии со спецификацией. Данный стандарт решает некоторые проблемы/ограничения PSR-0 и используется по умолчанию в Composer.
      Пример реализации

    Сейчас, сложно встретить разработчика, который бы смог рассказать о тонкостях работы автозагрузки в PHP, в основном все ссылаются на работу с Composer, не задумываясь как все устроено под капотом.

    В дополнение, оставлю ссылку на статью, которая подробно описывает работу с пространством имен, решенные проблемы и PSR-4.

    Интерфейсы


    PSR-Interfaces

    PHP развивается, набирает все большую популярность, а его инфраструктура пополняется огромным количеством различных инструментов.

    Появляются проблемы с изучением и переиспользованием однотипного функционала, а менеджер зависимостей может затянуть целую кучу несвязанных однотипных зависимостей. (тут JavaScript разработчик улыбнется).

    Поэтому принято решение стандартизировать некоторые общие концепции:

    • PSR-3: Logger Interface
      Основная цель данного интерфейса – простым и универсальным способом стандартизировать реализацию логирования. К данному интерфейсу прилагается спецификация, которая описывает в каких случаях какой из методов рекомендуется использовать.
      LoggerInterface
      interface LoggerInterface
      {
          public function emergency($message, array $context = array());
          public function alert($message, array $context = array());
          public function critical($message, array $context = array());
          public function error($message, array $context = array());
          public function warning($message, array $context = array());
          public function notice($message, array $context = array());
          public function info($message, array $context = array());
          public function debug($message, array $context = array());
          public function log($level, $message, array $context = array());
      }


      Если Ваш проект нуждается в расширенном функционале, МОЖНО расширять данный интерфейс, но СЛЕДУЕТ сохранять совместимость с описанными в данном стандарте правилами. Это позволит сторонним библиотекам, применяемых при разработке приложения, использовать централизованную систему логирования.

      На сегодняшний день нет необходимости самостоятельно реализовывать данный интерфейс (разве что в целях обучения), так-как существует отличное решение Monolog для реализации логирования, которое используется во многих проектах.
    • PSR-6: Caching Interface
      Кэширование широко используется для повышения производительности любого проекта.
      Кэширование так-же является одной из наиболее распространенных функций многих CMS, фреймворков и библиотек.

      Это привело к ситуации, когда многие библиотеки реализуют свои собственные системы кэширования с различными уровнями функциональности. Эти различия заставляют разработчиков изучать несколько систем, которые могут предоставлять или не предоставлять необходимую им функциональность. Кроме того, разработчики кеширующих библиотек сами сталкиваются с выбором между поддержкой только ограниченного числа платформ или созданием большого количества классов адаптеров.

      Чтобы решить эти проблемы был принят общий стандарт для библиотек реализующих кэширование, он включает в себя несколько интерфейсов:
      CacheItemInterface и CacheItemPoolInterface
      interface CacheItemInterface
      {
          public function getKey();
          public function get();
          public function isHit();
          public function set($value);
          public function expiresAt($expiration);
          public function expiresAfter($time);
      }

      interface CacheItemPoolInterface
      {
          public function getItem($key);
          public function getItems(array $keys = array());
          public function hasItem($key);
          public function clear();
          public function deleteItem($key);
          public function deleteItems(array $keys);
          public function save(CacheItemInterface $item);
          public function saveDeferred(CacheItemInterface $item);
          public function commit();
      }
      


      Наверное самая годная реализация PSR-6 это Symfony Cache. А вот одна из самых старых реализаций — это Laminas Cache (бывший Zend).
    • PSR-11: Container Interface
      Основная цель стандартизировать, как фреймворки и библиотеки будут использовать (DIC) контейнер для доступа к объектам и параметрам. Для этого был описан ContainerInterface.
      ContainerInterface
      interface ContainerInterface
      {
          public function get($id);
          public function has($id);
      }


      Спецификация PSR-11 не описывает то, как необходимо регистрировать зависимости в проекте, однако дает четкую рекомендацию как делать не нужно:
      Пользователи НЕ ДОЛЖНЫ передавать контейнер в объект, чтобы объект мог получить свои собственные зависимости. Это означает, что контейнер используется в качестве Service Locator, который обычно не рекомендуется использовать.
      Отсюда, возникает простой вопрос: «Как это вообще работает»?

      На самом деле все просто, на помощь приходит паттер Factory, который возьмет на себя задачу создания объекта. А вот сам класс фабрики уже может принимать ContainerInterface и передавать в создаваемый объект необходимые зависимости.
      Пример кода
      ConfigProvider
      [
          'invokables' => [
                // можно обойтись без фабрики, если класс не требует зависимостей
          ],
          'factories'  => [
              MyHandler::class => MyHandlerFactory::class,
          ],
      ];

      MyHandlerFactory
      class MyHandlerFactory
      {
          public function __invoke(ContainerInterface $container) : RequestHandlerInterface
          {
              $dep = $container->get(MyDepInterface::class);
      
              return new MyHandler($dep);
          }
      }

      MyHandler
      class MyHandler
      {
          private $dep;
          public function __construct(MyDepInterface $dep) 
          {
              $this->dep = $dep;
          }
          public function __invoke(ServerRequestInterface $request): RequestHandlerInterface
          {
               //
          }
      }


      Данный подход использует middleware framework Mezzio (это бывший Zend Expressive), что позволяет соблюдать принципы SOLID и получить дополнительную гибкость при создании объектов.
    • PSR-13: Hypermedia Links
      Не самый популярный стандарт, который предоставляет несколько интерфейсов, чтобы унифицировать общий формат hypermedia ссылок.
      LinkInterface, EvolvableLinkInterface и LinkProviderInterface EvolvableLinkProviderInterface
      LinkInterface
      interface LinkInterface
      {
          public function getHref();
          public function isTemplated();
          public function getRels();
          public function getAttributes();
      }

      EvolvableLinkInterface
      interface EvolvableLinkInterface extends LinkInterface
      {
          public function withHref($href);
          public function withRel($rel);
          public function withoutRel($rel);
          public function withAttribute($attribute, $value);
          public function withoutAttribute($attribute);
      }

      LinkProviderInterface
      interface LinkProviderInterface
      {
          public function getLinks();
          public function getLinksByRel($rel);
      }

      EvolvableLinkProviderInterface
      interface EvolvableLinkProviderInterface extends LinkProviderInterface
      {
          public function withLink(LinkInterface $link);
          public function withoutLink(LinkInterface $link);
      }


      В качестве примера, можно рассмотреть использование hypermedia ссылок в контексте HTML и в различных форматах API. При этом, если контекст использования ссылок в HTML понятен, то с API поможет разобраться статья "Hypermedia — то без чего Ваше API не совсем REST".
      Примеров использования данного стандарта не много: Symfony Web Link и Html Model.
    • PSR-14: Event Dispatcher
      Целью этого PSR является создание общего механизма для диспетчеризации событий, чтобы библиотеки и компоненты могли свободно использоваться в различных приложениях и средах. Для этого предоставляется несколько интерфейсов:
      EventDispatcherInterface, ListenerProviderInterface и StoppableEventInterface
      EventDispatcherInterface
      interface EventDispatcherInterface
      {
          public function dispatch(object $event);
      }

      ListenerProviderInterface
      interface ListenerProviderInterface
      {
          public function getListenersForEvent(object $event) : iterable;
      }

      StoppableEventInterface
      interface StoppableEventInterface
      {
          public function isPropagationStopped() : bool;
      }


      Диспетчеризация событий — это распространенный и хорошо протестированный механизм, позволяющий разработчикам легко и последовательно расширять логику приложения. Детально данный стандарт хорошо описывает статья "PSR-14 — главное событие в PHP".
      Чтобы попробовать в действии, предлагаю взглянуть на реализацию Symfony Event Dispatcher, YiiSoft Event Dispatcher и другие.
    • PSR-16: Simple Cache
      Обратите внимание на PSR-6, это действительно «мощная» спецификация для реализации системы кеширования, однако в большинстве проектов такая реализация может оказаться избыточной.

      Поэтому был принят PSR-16. Этот более простой подход направлен на создание стандартизированного оптимизированного интерфейса для общих случаев.
      CacheInterface
      interface CacheInterface
      {
          public function get($key, $default = null);
          public function set($key, $value, $ttl = null);
          public function delete($key);
          public function clear();
          public function getMultiple($keys, $default = null);
          public function setMultiple($values, $ttl = null);
          public function deleteMultiple($keys);
          public function has($key);
      }


      В списке реализаций все тот-же Symfony Cache и Laminas Cache (бывший Zend).


    HTTP


    PSR-HTTP

    Если речь идет о WEB-приложении, то не важно на сколько сложная в нем бизнес-логика, по факту оно делает всего 2 вещи — принимает Request и отдает Response. Это значит, что так или иначе, приходится реализовывать эти объекты у себя в проекте.

    Пожалуй, одной из самых сложных задач, которая нередко возникает является переиспользование кода между различными проектами. Если хорошо абстрагированные участки бизнес логики, некоторые компоненты и модули перенести возможно (с минимальными затратами), то с переносом более высокого уровня фреймворков (например контроллеров) возникают сложности.

    Группа PHP-FIG пытается исправить данную проблему и предоставляет стандарты абстракции над HTTP.

    • PSR-7: HTTP Message Interfaces
      Цель данного стандарта, предоставить общий набор интерфейсов для фреймворков, чтобы последние могли использовать одинаковые абстракции над Request и Response объектами. Это позволит разработчикам писать переиспользуемый, независимый от фреймворка код. Спецификация данного стандарта достаточно объемна:
      MessageInterface, RequestInterface, ServerRequestInterface, ResponseInterface, StreamInterface, UriInterface и UploadedFileInterface
      MessageInterface
      interface MessageInterface
      {
          public function getProtocolVersion();
          public function withProtocolVersion($version);
          public function getHeaders();
          public function hasHeader($name);
          public function getHeader($name);
          public function getHeaderLine($name);
          public function withHeader($name, $value);
          public function withAddedHeader($name, $value);
          public function withoutHeader($name);
          public function getBody();
          public function withBody(StreamInterface $body);
      }

      RequestInterface
      interface RequestInterface extends MessageInterface
      {
          public function getRequestTarget();
          public function withRequestTarget($requestTarget);
          public function getMethod();
          public function withMethod($method);
          public function getUri();
          public function withUri(UriInterface $uri, $preserveHost = false);
      }

      ServerRequestInterface
      interface ServerRequestInterface extends RequestInterface
      {
          public function getServerParams();
          public function getCookieParams();
          public function withCookieParams(array $cookies);
          public function getQueryParams();
          public function withQueryParams(array $query);
          public function getUploadedFiles();
          public function withUploadedFiles(array $uploadedFiles);
          public function getParsedBody();
          public function withParsedBody($data);
          public function getAttributes();
          public function getAttribute($name, $default = null);
          public function withAttribute($name, $value);
          public function withoutAttribute($name);
      }

      ResponseInterface
      interface ResponseInterface extends MessageInterface
      {
          public function getStatusCode();
          public function withStatus($code, $reasonPhrase = '');
          public function getReasonPhrase();
      }

      StreamInterface
      interface StreamInterface
      {
          public function __toString();
          public function close();
          public function detach();
          public function getSize();
          public function tell();
          public function eof();
          public function isSeekable();
          public function seek($offset, $whence = SEEK_SET);
          public function rewind();
          public function isWritable();
          public function write($string);
          public function isReadable();
          public function read($length);
          public function getContents();
          public function getMetadata($key = null);
      }

      UriInterface
      interface UriInterface
      {
          public function getScheme();
          public function getAuthority();
          public function getUserInfo();
          public function getHost();
          public function getPort();
          public function getPath();
          public function getQuery();
          public function getFragment();
          public function withScheme($scheme);
          public function withUserInfo($user, $password = null);
          public function withHost($host);
          public function withPort($port);
          public function withPath($path);
          public function withQuery($query);
          public function withFragment($fragment);
          public function __toString();
      }

      UploadedFileInterface
      interface UploadedFileInterface
      {
          public function getStream();
          public function moveTo($targetPath);
          public function getSize();
          public function getError();
          public function getClientFilename();
          public function getClientMediaType();
      }


      А более детальное описание с примерами можно разобрать в статье "PSR-7 в примерах".

      Laminas Diactoros (бывший Zend Diactoros) — является отличной реализацией PSR-7. И при этом в экосистеме PHP популярны симфони компоненты, среди которых Symfony HTTP-Foundation. Данный компонент не реализовал поддержку PSR-7, но предоставил мост, который ранее работал через Zend Diactoros, но сейчас использует другую имплементацию psr-7.
    • PSR-15: HTTP Handlers
      Спецификация данного стандарта описывает интерфейсы для обработчиков HTTP-запросов
      и компонентов промежуточного программного обеспечения HTTP-сервера.
      RequestHandlerInterface и MiddlewareInterface
      RequestHandlerInterface
      interface RequestHandlerInterface
      {
          public function handle(ServerRequestInterface $request): ResponseInterface;
      }

      MiddlewareInterface
      interface MiddlewareInterface
      {
          public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface;
      }


      Если не вдаваться во все тонкости, то по сути это возможность писать некие абстрактные контроллеры для последующего переиспользования между различными проектами.

      Middleware framework Mezzio (бывший Zend Expressie) отлично демонстрирует примеры реализации PSR-15.
    • PSR-17: HTTP Factories
      PSR-17 описывает общий стандарт для фабрик, которые создают HTTP-объекты, совместимые с PSR-7.

      PSR-7 не содержит рекомендации о том, как создавать HTTP-объекты. Это может приводить к трудностям при необходимости их создания внутри компонентов, которые не привязаны к конкретной реализации PSR-7.

      Интерфейсы, описанные в этой спецификации, описывают методы, с помощью которых можно создавать PSR-7 объекты.
      RequestFactoryInterface, ResponseFactoryInterface, ServerRequestFactoryInterface, StreamFactoryInterface, UploadedFileFactoryInterface и UriFactoryInterface
      RequestFactoryInterface
      interface RequestFactoryInterface
      {
          public function createRequest(string $method, $uri): RequestInterface;
      }

      ResponseFactoryInterface
      interface ResponseFactoryInterface
      {
          public function createResponse(int $code = 200, string $reasonPhrase = ''): ResponseInterface;
      }

      ServerRequestFactoryInterface
      interface ServerRequestFactoryInterface
      {
          public function createServerRequest(string $method, $uri, array $serverParams = []): ServerRequestInterface;
      }

      StreamFactoryInterface
      interface StreamFactoryInterface
      {
          public function createStream(string $content = ''): StreamInterface;
          public function createStreamFromFile(string $filename, string $mode = 'r'): StreamInterface;
          public function createStreamFromResource($resource): StreamInterface;
      }

      UploadedFileFactoryInterface
      interface UploadedFileFactoryInterface
      {
          public function createUploadedFile(
              StreamInterface $stream,
              int $size = null,
              int $error = \UPLOAD_ERR_OK,
              string $clientFilename = null,
              string $clientMediaType = null
          ): UploadedFileInterface;
      }

      UriFactoryInterface
      interface UriFactoryInterface
      {
          public function createUri(string $uri = '') : UriInterface;
      }


      Посмотреть пример использования PSR-17 можно в простой реализации PSR-7.
    • PSR-18: HTTP Client
      PSR-18 описывает общие интерфейсы для отправки PSR-7 HTTP-запросов и получения HTTP-ответов.
      ClientInterface, RequestExceptionInterface и NetworkExceptionInterface
      ClientInterface
      interface ClientInterface
      {
          public function sendRequest(RequestInterface $request): ResponseInterface;
      }

      RequestExceptionInterface
      interface RequestExceptionInterface extends ClientExceptionInterface
      {
          public function getRequest(): RequestInterface;
      }

      NetworkExceptionInterface
      interface NetworkExceptionInterface extends ClientExceptionInterface
      {
          public function getRequest(): RequestInterface;
      }


      Это может сделать библиотеки более пригодными для повторного использования, так как уменьшает количество зависимостей и снижает вероятность конфликтов версий.

      Также в спецификации указано, что HTTP-клиенты могут быть заменены согласно принципу подстановки Лисков. Это означает, что все клиенты ДОЛЖНЫ вести себя одинаково при отправке запроса.

      Пример реализации PSR-18 можно увидеть в библиотеке Symfony HTTP-client.

    Предложенная абстракция над HTTP — это весьма серьезная заявка на попытку реализовывать действительно переиспользуемые и не зависящие от конкретных библиотек и фреймворков полноценные решения.

    На практике, конечно все на много сложнее и есть свои нюансы и подводные камни, однако PHP-FIG делает значительный шаг вперед в этом направлении.

    Стиль кодирования


    code style

    До появления стандартов стиля кодирования, каждый из разработчиков оформлял свой код по-разному: одни писали CLASSNAME, другие ClassName, а третьи Class_Name, вечный спор относительно табов и пробелов, а еще StudlyCaps vs сamelCase vs snake_case и так далее.

    Цель следующих PSR стандартов уменьшить когнитивное искажение при чтении кода от разных авторов.

    • PSR-1: Basic Coding Standard
    • PSR-2 — Coding Style Guide Устарел
    • PSR-12: Extended Coding Style Guide

    Описанные выше спецификации достаточно объемные, поэтому мы рассмотрим только базовые из PSR-1:

    • Использование только тэгов <?php и <?=
    • Только UTF-8 без BOM для php кода
    • Не стоит мешать разный функционал в одном файле (1 файл = 1 класс)
    • Пространство имен и классы должны следовать [PSR-0, PSR-4]
    • Классы объявляются в `StudlyCase`
    • Константы объявляются в ТАКОМ_ВИДЕ
    • Методы объявляются в `camelCase`


    На самом деле, нет смысла помнить про кажный пункт о переносе скобки, пробеле, табе и т.п., так как существует различный функционал, который позволяет автоматически проверить и отформатировать кодовую базу по стандарту PSR-2/PSR-12:

    • Ручной режим: можно использовать reformat code в phpStorm.
    • Более продвинутый вариант: использовать какой-нибуть кодснифер, например PHP CS Fixer (часто используется в CI, чтобы не принимать коммиты с неотформатированным кодом).

    Автоматическое форматирование обычно выглядит так:


    А для достижения максимального профита можно расширить стандарты стиля кодирования руководством по написанию чистого кода.

    Преимущества использования PSR


    Сама аббревиатура PSR вышла за рамки простых рекомендаций относительно стиля кодирования. А группа PHP-FIG предлагает стандарты, которые предоставляют действительно мощную абстракцию для решения базовых проблем с переиспользованием различных инструментов и позволяет сделать код более независимым от конкретных реализаций и фреймворков (на практике все куда сложнее, но фундамент уже заложен).

    Для демонстрации хорошей абстракции рассмотрим установку middleware framework Mezzio:
    install

    Стандартизация в виде интерфейсов предоставляет возможность выбора любой имплементированной реализации. Также можно существенно облегчить написание документации ссылаясь на хорошо описанные PSR спецификации.

    И в заключение


    PSR — это действительно годные стандарты, которые созданы для того, чтобы решать проблемы переиспользования кода и облегчить совместную разработку. Однако использование PSR остается рекомендацией, поэтому Вы можете использовать как отдельные стандарты, так и не использовать их вообще.

    Лично я рекомендую использовать и делиться своим опытом с сообществом PHP.

    Спасибо, что дочитали до конца!
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 39

      –6
      Давно PSR стали стандартом? Или выдаете желаемое за действительное?
        +6
        Давно PSR стали стандартом?
        С момента появления.

        Скорей всего вы не правильно трактуете термин «стандарт». Стандарт это нормативный документ или свод правил. PSR как раз этим и является. В общем случае стандарт не является чем-то обязательным к исполнению. Любой желающий может написать свой стандарт. Можете создать проект на ГитХабе, написать свои правила для чего-либо и назвать это стандартом. Это будет абсолютно законно.
          –3

          Вот трактовка у вас точно такая же, как и у меня, а понимаем по разному. Разве может быть 2 стандарта "метра", "килограмма"? Нет, т.к. иначе ни один из них нельзя назвать стандартом, верно?

            0

            По идее да, например Английская система мер и метрическая система мер.

              –2
              В английской системе мер есть «метр»? Не знал.
              +1
              Разве может быть 2 стандарта «метра», «килограмма»
              Метры и килограммы являются часть системы единиц СИ. Никто не мешает вам создать свою единицу измерения (стандарт) и определить своё толкование метра и килограмма.
              Другое дело, как сделать свой стандарт «официальным». Т.е. чтобы он стал применятся организациями или даже государствами.
                –4
                > Другое дело, как сделать свой стандарт «официальным».
                Демагогия пошла… Это и есть "стандарт".

                По вашей логике получается, что если кто-то назовет python стандартом для php — это тоже будет «стандарт»?
                  0
                  По вашей логике получается, что если кто-то назовет python стандартом для php — это тоже будет «стандарт»?
                  Именно так. Стандарт вполне может быть абсурдным.
                    –4
                    Ну вот в этом и отличие в понимании «стандарта» между нами. Я считаю, что стандарт — это общепринятая и повсеместно используемая инструкция. Как «стандарт форматирования кода в go», например. Без этого просто не соберется приложениие. Или как «метр» — все его понимают и используют одинаково.

                    А psr, в моем понимании, рекомендация — не видел еще ни одного проекта, который был-бы реализован без нарушений этих рекомендаций.
                      0
                      > Я считаю, что стандарт — это общепринятая и повсеместно используемая инструкция.

                      это имеет другое название. «Стандарт де-факто»
                +1
                Вон у «килобайта» два стандарта и ничего. По одному в нём 1000 байт, а по другому — 1024.
              0
              ))) Странно, что заминусован пока что единственный адекватный комментарий
              0
              Если бы меня под давлением спросили что такое psr то сразу бы сказал про стандарт оформления. Просто забывается что это еще и интерфейсы, и прочее. Поэтому, наверное, стоит задавать наводящий вопрос.
              Спасибо за описание.
                0
                Не все так жестоко :). Дальше задаются вопросы по конкретным стандартам, которые используются в нашем проекте. PSR стандарты не так сложно изучить, поэтому их знание скорее небольшой бонус, чем жесткое требование.
                +1

                Странно, что автозагрузку классов по PSR-4 не добавили в сам PHP, чтобы не нужно было для каждого файла запускать код на PHP. В PHP автозагрузка есть, но вся проблема в том, что папки с именами пространств имён и файлы с классами должны быть преобразованы к нижнему регистру.


                Если кратко, то чтобы включить автозагрузку в PHP нужно выполнить 3 шага:


                • добавить папку с классами в include_path;
                • указать окончание для файлов с классами (например, .php или .class.php);
                • зарегистрировать автозагрузчик.

                set_include_path(get_include_path().':'.__DIR__.'/../classes/');
                spl_autoload_extensions('.php');
                spl_autoload_register();

                После этого все классы из всех пространств имён начинают "магическим образом" подгружаться.

                  +1

                  Я когда-то давно наступал на посты о том, что разработки PHP крайне аккуратно подходят к фичам, которые ломают обратную совместимость. А такое решение бы похоронило тонны легаси.

                    0

                    А зачем менять дефотное поведение? Просто добавить возможность загружать из папок так, как требует PSR-4.

                      0

                      PSR-4 немного противоречит логике языка, поэтому вряд ли будет в него когда-либо включен. В PHP имена классов регистронезависимые, а автозагрузка по PSR регистрозависимая на регистрозависимых файловых системах


                      папки с именами пространств имён и файлы с классами должны быть преобразованы к нижнему регистру

                      оно же не просто так

                  0
                  Когда-то сам считал PSR исключительно стилем, и справедливости ради, чаще всего использование PSR ограничивается первыми тремя стейджами. А во всех других задачах часто просто тащатся компоненты симфони.

                  Сам подход хорош и должен развиваться. Если стандарт охватит большинство типовых конструкций и идиом, это может улучшить качество кодовой базы по языку в целом, избавив проекты новичков от особенно лютых костылей. Другое дело, что это немного дизмотивирует разработку своих велосипедов, что в 0.1% случаев может приводить к появлению лучшего способа запилить фичу.
                    0

                    Исправить надо, namespace появились с 5.4

                    +1
                    psr-fig похоронила отличную идею годы назад.
                    Изучите почему симфони и доктрина покинули группу.
                    Почему psd-5 phpDoc все еще не принят за декаду, хотя phpDocumentor была в группе почти с основания

                    Я не говорю, что стандарты плохие и их надо игнорировать. Я говорю что для общества надо было принять сотню маленьких стандартов за прошедую декаду. А не разрабатываеть переусложненные стандарты по 5 лет, занимаясь срачем вместо помощи обществу.
                      0
                      занимаясь срачем вместо помощи обществу.
                      Собственно PHP-FIG и представляет сообщество через его представителей от различных PHP фреймворков и CMS. Срач это вполне привычное явление при обсуждения холиварных вопросов. Мнений много, а результат должен быть один. Несогласные уходят.
                      twitter.com/fabpot/status/1064946913596895232
                        0
                        > PHP-FIG и представляет сообщество

                        уже нет.

                        > Срач это вполне привычное явление

                        как таковой — да. Одеако мы имеем губительную разновидность — срач который блокирует принятие решения и движения вперед. Кстати, такой же губительный срач накрыл сам пых с php4 по php53

                        > Мнений много, а результат должен быть один.

                        Совершенно нет. Результатов может быть несколько. Любой стандарт передачи данных — выберете себе одну из скоростей в ущерб другому параместру. Более того, половина (ну 7 лет назад так точно) учестников FIG не соблюдают PSR-2 во всей его полноте.

                        Еще раз. Стандарты — это то к чему надо стремится, а не все обязаны их всегда выполнять. И работа FIG должна была быть не в том, чтобы дать площадку для срача устоявшихся проектов. А создать стандарты к которым хочется стремится. На которые легко переходить. Дать инструкции (а в идеали и инструменты) чтобы переходить на стандарты.

                        Все понимали, что невозможно создать интерфейс DI на который рефакторнутся все фреймворки. Потому что у фреймверков свое легаси, свое комюнити и обязательства. Но сделать достаточно простой стандарт, чтобы каждый (сперва синьер, а потом сам фреймворк) мог сделать фасад на этот стандарт. И оп-па мы получаем результат, который постулировался в день создания группы. До тех пор пока я пишу код с интерфейсом стандарта (а не самого фреймворка) — я могу за полдня заменить DI на любой другой.
                        0
                        Изучите почему симфони и доктрина покинули группу.
                        Можно для тех кто из леса, вкратце объяснить?
                          0
                          Знаю про только про симфони. Это было тогда, когда приняли PSR-14.
                          Подробнее: medium.com/@tdutrion/symfony-and-psr-14-event-dispatcher-f5a9db6740e7

                          Если в 2 словах, то релиз стандарта попал под LTS версию симфони, которая должна была еще н-время поддерживать php5.6. А данный стандарт использовал тип данных object и ограничивал использование версий php 7.0+.

                          Я не совсем понимаю почему из-за этого нужно было покидать PHP-FIG, так-как на сегодняшний день компоненты симфони поддерживают PSR и PSR-14 тоже доехал.
                            0
                            psr-14 был просто последней каплей.
                            По сути — они тратили годы на пустые обсуждения и не могли нигде найти компромиса и дойти до релизов.
                            Первая причина — потому что стандарты были раздуты
                              0

                              Даже не раздуты, а их нельзя было реализовать в актуальных на тот момент компонентах (symfony/http-foundation, doctrine/cache etc), т.е. это никак не interoperability group.
                              Вот тут выжимка: https://hub.packtpub.com/symfony-leaves-php-fig-the-framework-interoperability-group/

                                0
                                мое лично мнение

                                Именно раздутость не дает возможности реализации. То есть если бы топ-5 фреймворков сделали идеальный стандарт и сразу имплементировали его. Из-за его размеров — он бы все равно подошел только для некоторых. И некоторых в этом случае — для меньшинства (хоть и часто используемого).

                                Смотрим на стандарт логгера. Он настолько маленький — что я (лично, без помощи) могу его подключить в любой проект. Обернуть над любой либой или модулем. Если надо будет — даже без отдельного таска в трекере.
                        0

                        С выходом php7 большую часть кода и стандарта можно упростить, например через type hint
                        Реализовывал psr-16 кэшер файлов
                        Вот там описание гласит, например аргумент должен быть массив или DateTime, значит надо реализовать проверку, в php7 можно указать тип
                        Есть даже заготовки в виде утилит, но для кэша пустой ( https://github.com/php-fig/simplecache-util) пришлось чуть подсмотреть в заготовки psr-6 ( https://github.com/php-fig/cache-util )

                          0
                          $this->CI->load->helper('captcha');
                          $this->CI->load->helper('cookie');
                          $this->CI->load->helper('email');
                          

                          Напишите в комментариях, если узнали где использовался данный подход

                          Очень похоже на service locator'ы в СodeIgniter. По тем временам, было очень удобно на нем писать, да и альтернатив особо не было.
                          –2
                          PHP развивается, набирает все большую популярность...

                          Статистика, к сожалению, говорит об обратном:
                            +3
                            Тут смотря с какой стороны смотреть.

                            Разработчики PHP весьма оживились, за последние несколько лет были серьезные прогрессы в производительности, новые фичи, RFC и тп. Технология активно развивается (ждем PHP 8).

                            Что касается рейтинга: www.tiobe.com/tiobe-index
                            Мне кажется, это не совсем тот рейтинг, который стоит воспринимать, как показатель жизнеспособности языка(технологии).

                            Так-как многие инструменты заточены под конкретные ниши и сравнивать их в общем я бы не стал. Например в этот рейтинг на 20 позицию попал Scratch.

                            PHP достаточно давно и стабильно занял свою нишу и пока все идет хорошо.

                              0
                              Я именно про популярность. С развитием у языка, как вы написали, действительно все хорошо. Спад популярности на графике с 2010 года, полагаю, связан с появлением/распространением новых языков/технологий. Появился nodejs, go. Django, рельсы и другие web-фреймфорки стали набирать популярность. Кто-то перешел на них с PHP, кто-то начал изучать их, как первый язык. Конечно же, это не могло не отразиться на популярности PHP.
                                0

                                Тут ещё надо различать абсолютную и относительную популярность. Первая может расти одновременно с падением второй. Грубо говоря, сообщество использующих PHP увеличивается каждый год на 100 000 человек (с учётом переставших использовать), а вообще сообщество использующих разные ЯП растёт быстрее, в результате чего доля PHP падает.

                                0
                                Например в этот рейтинг на 20 позицию попал Scratch.

                                Это достаточно популярный язык для обучения детей программированию. У коллеги сын ходит на курсы по робототехнике, там его используют для программирования роботов.
                              0
                              Познавательно. Особенно в части ссылок на рекомендации по «чистому коду». Спасибо.

                              Only users with full accounts can post comments. Log in, please.