D 2014-09-02T20:33:08.894
L FeatureComparison
N text/x-markdown
P 979cde52ced37195ce4daba5685d8edf82a7af1f
U mario
W 4034
Let me just preface this with: inconclusive conventions are better than no standards at all. And there's probably nothing newsworthy here.<br>
Due to the ellipses in the PSR-x documents it's however helpful to detail some technical deviations and oversights.
<style>
.yes { background: #bbeebb; }
.no { background: #eeccbb; }
.part { background: #eedd99; }
td, th { text-align: center; }
td:first-child { text-align: left; font-weight: normal; }
ol { }
</style>
<table width=100%>
<tr>
<td style="text-align:left"><b>Feature</b>
<th>PHP
<th>PSR-0
<th>PSR-4
<th>shared
<tr>
<td class=yes>Class autoloading
<td class=yes>✔
<td class=yes>✔
<td class=yes>✔
<td class=yes>✔
<tr>
<td>Zero configuration
<td class=yes>✔
<td class=yes> ✔
<td class=no>✘
<td class=no>✘
<tr>
<td>Multiple class declarations per script
<td class=yes>✔
<td class=no>✘ ¹
<td class=no>✘ ¹
<td class=yes>✔
<tr>
<td>Namespace support
<td class=yes title="optional">✔
<td class=yes title="predicate">✔
<td class=yes title="prediacte">✔
<td class=yes title="optional">✔
<tr>
<td>Multiple namespaces per file
<td class=yes>✔
<td class=no>✘
<td class=no>✘
<td class=yes>✔
<tr>
<td>Syntax verification
<td class=yes>✔
<td class=no>✘
<td class=no>✘
<td class=part title="Only partially with the tokenizer update.">✘
<tr>
<td>Specific underscore treatment
<td class=yes>✘
<td class=yes> ✔
<td class=yes>✘
<td class=yes>✘
<tr>
<td class=yes title="Cross-plattform unambiguousness">Case-insensitive class identifiers ²
<td class=yes>✔
<td class=no>✘
<td class=no>✘ ²
<td class=yes>✔
<tr>
<td>Function names
<td class=yes>✔
<td class=no>ⁿ/ₐ
<td class=no>ⁿ/ₐ
<td class=yes>✔
<tr>
<td>Case-variant constants
<td class=yes>✔
<td class=no>ⁿ/ₐ
<td class=no> ⁿ/ₐ
<td class=part>✘
<tr>
<td class=yes>Phar package support
<td class=yes>✔
<td class=part>✘ ³
<td class=no>✘
<td class=yes>✔
<tr>
<td>Versioned bundles ⁴
<td class=part>✔
<td class=no>✘
<td class=no>✘
<td class=no>✘
<tr>
</table>
<ol>
<li> Impractical, but symlinking dependency-conjoined class modules might be a feasible workaround.<br>
<li> Not just accidentally on some plattforms or filesystems.<br>
<li> While prohibited, most PSR-0 autoloaders work with handicrafted phar:// paths in their namespace registry.<br>
<li> Not a discreet PHP or Phar feature, and resolving dependencies is certainly still best left with composer, not done at runtime.<br>
</ol>
#### Origin of PSR-0/4
PSR-4 inherits the PSR-0 design as intended for and from PHP framework maintainers. Retaining the traditional class directory structures was the [protogenic goal](http://news.php.net/php.standards/start/1) then. PSR-4 constitutively just removed the PEAR-style name splitting.
Which is where the plattform ambiguity due to absent identifier-to-file case normalization issues from. Holding on to the handed down file structuring schemes is also why namespaces were interpreted as PHP 5.3s only significant addition, but Phar support disregarded.
#### Composer relationship
[Composer](wiki/Composer) is married to PSR-0/4. Technically it's not a dependency, as highlighted by Composers very own classmap generator. (Which however infers the shallow semantics of singly-namespaced-class-per-file, invalid identifier mapping, zilch phar support).
Divorcing your way out of an abusive marriage is no small feat. Yet composer may keep the kids. When extracting packages, it's neither out of the picture to apply some common sense and `strtolower`, or repackage coherent bundles into phars. Thus development sources still may follow any of the framework guidelines, yet be used unambiguously cross-plattform.
Z 5f6d61dd0c7829ac7962260a87c8c07d