Map-based autoloader across php and phar resources

โŒˆโŒ‹ โŽ‡ branch:  Canonic Autoloader


Artifact Content

Artifact ad6ecaf1bb210163846d1be6f9d120873f805bd8:

Wiki page [FeatureComparison] by mario 2014-09-04 02:08:08.
D 2014-09-04T02:08:08.210
L FeatureComparison
N text/x-markdown
P 9eb2a4de0db7232aefc06b97ac615298b8c9214b
U mario
W 3816
Let me just preface this with: inconclusive conventions are better than no standards at all. And there's really nothing <i>news</i>worthy 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=no>โœ˜โ€Šยณ
  <td class=part>โœ˜โ€Šโ€Šยณ
  <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.
 <li> Not just accidentally on some plattforms or filesystems.
 <li> While prohibited, some PSR-0 and a few PSR-4 autoloaders work with handicrafted phar:// paths in their namespace registry.
 <li> Dependency resolution is mostly off-scope for runtime autoloading, and obviously best left with composer.
</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 absent identifier-to-file case normalization issues from. The focus on legacy directory schemes is also how Phar support got completely disregarded (as if PHP 5.3 was only about namespacing all the things).


#### 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 stockholm-syndromes the shallow singly-namespaced-class-per-file semantics, invalid identifier mapping, and overlooked phar support).

As package installation mediator it can however abstract away some source management deficiencies. Applying some late common sense and `strtolower` becomes a facile possibility.



Z 7a852c507d70078ae3efaca0741fd9b3