diff --git a/accepted/PSR-0.md b/accepted/PSR-0.md index ca277d862..47957525b 100644 --- a/accepted/PSR-0.md +++ b/accepted/PSR-0.md @@ -21,7 +21,7 @@ Mandatory * Each `_` character in the CLASS NAME is converted to a `DIRECTORY_SEPARATOR`. The `_` character has no special meaning in the namespace. -* The fully-qualified namespace and class is suffixed with `.php` when +* The fully-qualified namespace and class are suffixed with `.php` when loading from the file system. * Alphabetic characters in vendor names, namespaces, and class names may be of any combination of lower case and upper case. diff --git a/accepted/PSR-3-logger-interface.md b/accepted/PSR-3-logger-interface.md index 0098f44c5..9642471e6 100644 --- a/accepted/PSR-3-logger-interface.md +++ b/accepted/PSR-3-logger-interface.md @@ -29,7 +29,7 @@ Users of loggers are referred to as `user`. [RFC 5424][] levels (debug, info, notice, warning, error, critical, alert, emergency). -- A ninth method, `log`, accepts a log level as first argument. Calling this +- A ninth method, `log`, accepts a log level as the first argument. Calling this method with one of the log level constants MUST have the same result as calling the level-specific method. Calling this method with a level not defined by this specification MUST throw a `Psr\Log\InvalidArgumentException` @@ -120,7 +120,7 @@ Users of loggers are referred to as `user`. - The `Psr\Log\NullLogger` is provided together with the interface. It MAY be used by users of the interface to provide a fall-back "black hole" - implementation if no logger is given to them. However conditional logging + implementation if no logger is given to them. However, conditional logging may be a better approach if context data creation is expensive. - The `Psr\Log\LoggerAwareInterface` only contains a @@ -136,7 +136,7 @@ Users of loggers are referred to as `user`. ---------- The interfaces and classes described as well as relevant exception classes -and a test suite to verify your implementation is provided as part of the +and a test suite to verify your implementation are provided as part of the [psr/log](https://packagist.org/packages/psr/log) package. 3. `Psr\Log\LoggerInterface` diff --git a/accepted/PSR-4-autoloader-meta.md b/accepted/PSR-4-autoloader-meta.md index d1fa339ac..437ad26df 100644 --- a/accepted/PSR-4-autoloader-meta.md +++ b/accepted/PSR-4-autoloader-meta.md @@ -31,7 +31,7 @@ pseudo-namespaces, like so: With the release of PHP 5.3 and the availability of namespaces proper, PSR-0 was introduced to allow both the old Horde/PEAR underscore mode *and* the use of the new namespace notation. Underscores were still allowed in the class -name to ease transition from the older namespace naming to the newer naming, +name to ease the transition from the older namespace naming to the newer naming, and thereby to encourage wider adoption. /path/to/src/ @@ -75,7 +75,7 @@ like this: The "src" and "tests" directories have to include vendor and package directory names. This is an artifact of PSR-0 compliance. -Many find this structure to be deeper and more-repetitive than necessary. This +Many find this structure to be deeper and more repetitive than necessary. This proposal suggests that an additional or superseding PSR would be useful so that we can have packages that look more like the following: @@ -203,7 +203,7 @@ Cons: ### 4.3 Alternative: Split Up Autoloading And Transformation Beau Simensen and others suggested that the transformation algorithm might be -split out from the autoloading proposal, so that the transformation rules +split out from the autoloading proposal so that the transformation rules could be referenced by other proposals. After doing the work to separate them, followed by a poll and some discussion, the combined version (i.e., transformation rules embedded in the autoloader proposal) was revealed as the @@ -211,7 +211,7 @@ preference. Pros: -- Transformation rules could be referenced separately by other proposal +- Transformation rules could be referenced separately by other proposals Cons: diff --git a/accepted/PSR-6-cache.md b/accepted/PSR-6-cache.md index e9fcd8671..f4055938b 100644 --- a/accepted/PSR-6-cache.md +++ b/accepted/PSR-6-cache.md @@ -136,7 +136,7 @@ at any time. While caching is often an important part of application performance, it should never be a critical part of application functionality. Thus, an error in a cache system SHOULD NOT -result in application failure. For that reason Implementing Libraries MUST NOT +result in application failure. For that reason, Implementing Libraries MUST NOT throw exceptions other than those defined by the interface, and SHOULD trap any errors or exceptions triggered by an underlying data store and not allow them to bubble. diff --git a/accepted/PSR-7-http-message-meta.md b/accepted/PSR-7-http-message-meta.md index 38d776935..9ce3fe1a5 100644 --- a/accepted/PSR-7-http-message-meta.md +++ b/accepted/PSR-7-http-message-meta.md @@ -505,7 +505,7 @@ $foo = isset($request->getBodyParams()['foo']) The argument for using "parsed body" was made by examining the domain. A message body can contain literally anything. While traditional web applications use forms and submit data using POST, this is a use case that is quickly being -challenged in current web development trends, which are often API centric, and +challenged in current web development trends, which are often API-centric, and thus use alternate request methods (notably PUT and PATCH), as well as non-form-encoded content (generally JSON or XML) that _can_ be coerced to arrays in many cases, but in many cases also _cannot_ or _should not_. @@ -515,7 +515,7 @@ developers then need a shared convention about where to put the results of parsing the body. These might include: - A special key under the body parameters, such as `__parsed__`. -- A special named attribute, such as `__body__`. +- A specially named attribute, such as `__body__`. The end result is that a developer now has to look in multiple locations: @@ -602,7 +602,7 @@ requiring paragraphs of implementation specification for an array, we specify an interface. Additionally, the data in an `UploadedFileInterface` is normalized to work in -both SAPI and non-SAPI environments. This allows creation of processes to parse +both SAPI and non-SAPI environments. This allows the creation of processes to parse the message body manually and assign contents to streams without first writing to the filesystem, while still allowing proper handling of file uploads in SAPI environments. diff --git a/accepted/PSR-7-http-message.md b/accepted/PSR-7-http-message.md index ebd0877ec..1ad8d95ed 100644 --- a/accepted/PSR-7-http-message.md +++ b/accepted/PSR-7-http-message.md @@ -296,9 +296,9 @@ account Common Gateway Interface (CGI), and, more specifically, PHP's abstraction and extension of CGI via its Server APIs (SAPI). PHP has provided simplification around input marshaling via superglobals such as: -- `$_COOKIE`, which deserializes and provides simplified access for HTTP +- `$_COOKIE`, which deserializes and provides simplified access to HTTP cookies. -- `$_GET`, which deserializes and provides simplified access for query string +- `$_GET`, which deserializes and provides simplified access to query string arguments. - `$_POST`, which deserializes and provides simplified access for urlencoded parameters submitted via HTTP POST; generically, it can be considered the @@ -934,7 +934,7 @@ namespace Psr\Http\Message; * - Headers * - Message body * - * Additionally, it encapsulates all data as it has arrived to the + * Additionally, it encapsulates all data as it has arrived at the * application from the CGI and/or PHP environment, including: * * - The values represented in $_SERVER. @@ -1435,7 +1435,7 @@ namespace Psr\Http\Message; * state of the current instance and return an instance that contains the * changed state. * - * Typically the Host header will be also be present in the request message. + * Typically the Host header will also be present in the request message. * For server-side requests, the scheme will typically be discoverable in the * server parameters. *