Stack Overflow is a community of 4.7 million programmers, just like you, helping each other.

Join them; it only takes a minute:

Sign up
Join the Stack Overflow community to:
  1. Ask programming questions
  2. Answer and help your peers
  3. Get recognized for your expertise

When I was digging into the source of a Composer package on github I noticed that there were php files that matched namespace names but were preceded with an underscore. Puzzled I pulled the package down (via Composer) and noticed that the class loader that Composer generates required these underscored files explicitly, not autoloading as I'd expected.

For instance, in the crunch/regular-expression package there is a namespace called Crunch\RegularExpression:

-- src
---- Crunch
------- RegularExpression       <-- folder containing classes
------- _RegularExpression.php  <-- file namespace to Crunch/RegularExpression
                                    containing functions and constants 
                                    (instead of a class)

Initially I thought these underscored files were a feature of PSR-0 that I had missed, but then I looked at the Composer generated autoload_real.php and saw that _RegularExpression.php (amongst others) was being required explicitly:

…
$loader->register(true);

require $baseDir . '/src/Crunch/_RegularExpression.php';
require $baseDir . '/src/Crunch/RegularExpression/_Modifier.php';
require $baseDir . '/src/Crunch/RegularExpression/Pattern/_Modifier.php';
require $baseDir . '/src/Crunch/RegularExpression/Pattern/_Assertion.php';

return $loader;
…

Haven't been able to find any meaningful documentation about this feature of Composer. Is it a good "standard" for exporting non-class based namespaced dependencies, like functions and constants?

Update

My question turned out to be a slight misnomer. The selected answer lead me to discover that non-class based assets can be explicitly declared for loading in composer.json:

"autoload": {
    "psr-0": { "Crunch\\RegularExpression": "src" },
    "files": [
        "src/Crunch/_RegularExpression.php",
        "src/Crunch/RegularExpression/_Modifier.php",
        "src/Crunch/RegularExpression/Pattern/_Modifier.php",
        "src/Crunch/RegularExpression/Pattern/_Assertion.php"
    ]
}

The underscores on the files were a convention used to delineate them from class definitions and have no special purposes in autoloading.

share|improve this question
up vote 10 down vote accepted

Composer doesn't treat those files in any special way. The package author in this case used this as some sort of convention to stores functions it seems.

The files are required by Composer because they're defined as "files" autoload in the composer.json, not because of some black magic on filenames.

share|improve this answer
    
AHHHHH. Thank you, that helps! Re: best practices, is this an acceptable practice for Composer packages, to export non-class-based elements? I imagine since they are namespaced it's a safe practice. – Mark Fox Apr 29 '13 at 20:59
    
@MarkFox: What do you mean by "export" exactly? And what constitutes a "non-class-based element"? Please elaborate. Regarding best practices: There are none, it is what Composer offers by default, even if you didn't know that, and any of the options this feature comes with are best practice in the sense that they work and that they are supported: getcomposer.org/doc/01-basic-usage.md – M8R-1jmw5r Apr 29 '13 at 23:00
    
Export meaning make available. I have borrowed the word, possibly incorrectly. In the package refernced in my question (crunch/regular-epxressions) the files preceded with underscores (apparently the authors own convention?) don't contain Classes but contain namespaced constants and functions. It was a neat approach that I like because it avoided creating a class entirely composed of static elements, instead using a namespace alias for brevity. It's clear if you grab the package I think. Hopefully you understand what I mean by export now. – Mark Fox Apr 29 '13 at 23:44
2  
@MarkFox it's definitely acceptable, but if it's functions that are seldom used, I would recommend wrapping in a class so it can be autoloaded rather than being force-required at every request. – Seldaek Apr 30 '13 at 7:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.