at php|tek, Chicago, in 2009. Since then various other members have applied and been voted in, increasing the size of the group from the first 5 to over 20. PHP-FIG
from file paths. It is fully interoperable, and can be used in addition to any other autoloading specification, including PSR-0. This PSR also describes where to place files that will be autoloaded according to the specification.
a top-level namespace name, also known as a "vendor namespace". • The fully qualified class name MAY have one or more sub-namespace names. • The fully qualified class name MUST have a terminating class name. • Underscores have no special meaning in any portion of the fully qualified class name. • Alphabetic characters in the fully qualified class name MAY be any combination of lower case and upper case. • All class names MUST be referenced in a case-sensitive fashion.
a fully qualified class name ... ◦ A contiguous series of one or more leading namespace and sub-namespace names, not including the leading namespace separator, in the fully qualified class name (a "namespace prefix") corresponds to at least one "base directory". ◦ The contiguous sub-namespace names after the "namespace prefix" correspond to a subdirectory within a "base directory", in which the namespace separators represent directory separators. The subdirectory name MUST match the case of the sub-namespace names. ◦ The terminating class name corresponds to a file name ending in .php. The file name MUST match the case of the terminating class name. ◦ \<NamespaceName>(\<SubNamespaceNames>)*\<ClassName> • Autoloader implementations MUST NOT throw exceptions, MUST NOT
= array(); public function register() { spl_autoload_register(array($this, 'loadClass')); } public function addNamespace($prefix, $base_dir, $prepend = false) ... public function loadClass($class) ... protected function loadMappedFile($prefix, $relative_class) ... protected function requireFile($file) … }
<?= tags. • Files MUST use only UTF-8 without BOM (byte order marks ) for PHP code. • Files SHOULD either declare symbols (classes, functions, constants, etc.) or cause side-effects (e.g. generate output, change .ini settings, etc.) but SHOULD NOT do both. • Namespaces and classes MUST follow an "autoloading" PSR: [PSR-0, PSR-4]. • Class names MUST be declared in StudlyCaps. • Class constants MUST be declared in all upper case with underscore separators. • Method names MUST be declared in camelCase.
effect: change ini settings ini_set('error_reporting', E_ALL); // side effect: loads a file include "file.php"; // side effect: generates output echo "<html>\n"; // declaration function foo() { // function body }
function foo() { // function body } // conditional declaration is *not* a side effect if (! function_exists('bar')) { function bar() { // function body } }
declared in all upper case with underscore separators. <?php namespace Vendor\Model; class Foo { const VERSION = '1.0'; const DATE_APPROVED = '2012-06-01'; }
recommendation regarding the use of $StudlyCaps, $camelCase, or $under_score property names. Whatever naming convention is used SHOULD be applied consistently within a reasonable scope. That scope may be vendor-level, package-level, class-level, or method-level.
PSR-1, the basic coding standard. The intent of this guide is to reduce cognitive friction when scanning code from different authors. It does so by enumerating a shared set of rules and expectations about how to format PHP code. The style rules herein are derived from commonalities among the various member projects. When various authors collaborate across multiple projects, it helps to have one set of guidelines to be used among all those projects. Thus, the benefit of this guide is not in the rules themselves, but in the sharing of those rules.
style guide" PSR [PSR-1]. • Code MUST use 4 spaces for indenting, not tabs. • There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less. • There MUST be one blank line after the namespace declaration, and there MUST be one blank line after the block of use declarations. • Opening braces for classes MUST go on the next line, and closing braces MUST go on the next line after the body.
all properties and methods; abstract and final MUST be declared before the visibility; static MUST be declared after the visibility. • Control structure keywords MUST have one space after them; method and function calls MUST NOT. • Opening braces for control structures MUST go on the same line, and closing braces MUST go on the next line after the body. • Opening parentheses for control structures MUST NOT have a space after them, and closing parentheses for control structures MUST NOT have a space before.
logging libraries. The main goal is to allow libraries to receive a Psr\Log\LoggerInterface object and write logs to it in a simple and universal way. Frameworks and CMSs that have custom needs MAY extend the interface for their own purpose, but SHOULD remain compatible with this document. This ensures that the third-party libraries an application uses can write to the centralized application logs.
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()); }
the performance of any project, making caching libraries one of the most common features of many frameworks and libraries. This has lead to a situation where many libraries roll their own caching libraries, with various levels of functionality. These differences are causing developers to have to learn multiple systems which may or may not provide the functionality they need. In addition, the developers of caching libraries themselves face a choice between only supporting a limited number of frameworks or creating a large number of adapter classes. A common interface for caching systems will solve these problems. Library and framework developers can count on the caching systems working the way they're expecting, while the developers of caching systems will only have to implement a single set of interfaces rather than a whole assortment of adapters.
PHP data types, including: • Strings - Character strings of arbitrary size in any PHP-compatible encoding. • Integers - All integers of any size supported by PHP, up to 64-bit signed. • Floats - All signed floating point values. • Boolean - True and False. • Null - The actual null value. • Arrays - Indexed, associative and multidimensional arrays of arbitrary depth. • Object - Any object that supports lossless serialization and deserialization.
a collection of items in a caching system. The pool is a logical Repository of all items it contains. All cacheable items are retrieved from the Pool as an Item object, and all interaction with the whole universe of cached objects happens through the Pool. • Items An Item represents a single key/value pair within a Pool. The key is the primary unique identifier for an Item and MUST be immutable. The Value MAY be changed at any time.
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();
invalid cache arguments. * * Any time an invalid argument is passed into a method it must throw an * exception class which implements Psr\Cache\InvalidArgumentException. */ interface InvalidArgumentException extends CacheException { }
requests, the Host header typically mirrors the host component of the URI, as well as the host used when establishing the TCP connection. However, the HTTP specification allows the Host header to differ from each of the two. This table illustrates what getHeaderLine('Host') will return for a request returned by withUri() with the $preserveHost argument set to true for various initial requests and URIs.
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); PSR-7: interface MessageInterface
public function getMethod(); public function withMethod($method); public function getUri(); public function withUri(UriInterface $uri, $preserveHost = false); } PSR-7: RequestInterface extends MessageInterface
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); PSR-7: interface ServerRequestInterface extends RequestInterface
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); PSR-7: interface StreamInterface
important part of the web, in both HTML contexts and various API format contexts. However, there is no single common hypermedia format, nor is there a common way to represent Links between formats. This specification aims to provide PHP developers with a simple, common way of representing a hypermedia link independently of the serialization format that is used. That in turn allows a system to serialize a response with hypermedia links into one or more wire formats independently of the process of deciding what those links should be.
the following definitions apply. • Implementing Object -An object that implements one of the interfaces defined by this specification. • Serializer - A library or other system that takes one or more Link objects and produces a serialized representation of it in some defined format.
the following definitions apply. • Implementing Object -An object that implements one of the interfaces defined by this specification. • Serializer - A library or other system that takes one or more Link objects and produces a serialized representation of it in some defined format. All links MAY include zero or more additional attributes beyond the URI and relationship.
and are either a simple keyword in case of a publicly defined relationship or an absolute URI in the case of a private relationships. In case a simple keyword is used, it SHOULD match one from the IANA registry at: http://www.iana.org/assignments/link-relations/link-relations.xhtml Optionally the microformats.org registry MAY be used, but this may not be valid in every context: http://microformats.org/wiki/existing-rel-values A relationship that is not defined in one of the above registries or a similar public registry is considered "private", that is, specific to a particular application or use case. Such relationships MUST use an absolute URI.
format for URI templates, that is, a pattern for a URI that is expected to be filled in with values provided by a client tool. Some hypermedia formats support templated links while others do not, and may have a special way to denote that a link is a template. A Serializer for a format that does not support URI Templates MUST ignore any templated Links it encounters.
interface for dependency injection containers. • The goal set by ContainerInterface is to standardize how frameworks and libraries make use of a container to obtain objects and parameters (called entries in the rest of this document).