[nycphp-talk] php autoloading
Paul A Houle
paul at devonianfarm.com
Fri Jan 16 14:44:51 EST 2009
Paul M Jones wrote:
> At the risk of sounding flippant, you could "[assume] a certain
> convention for how file names relate to class names" and use six lines
> of code for autoloading. The PEAR naming convention is perfect for
> this. Underscores in class names map to subdirectories, so the
> transformation of class name to file path is trivial.
>
I think the PEAR naming convention is wack, I may be fighting a
losing battle against the CamelCaseSelfishMeme, but I'm on this side:
http://dontcuddleyourbraces.blogspot.com/2007/10/against-camelcase.html
It's particularly disasterous that PHP has embraced the convention
from Java (maybe we think it makes us look sophisticated and cool)
because dynamic generation of filenames, class names and method names
is much more common in PHP than it is in Java. PHPers who want to write
reliable programs need 100% reliable and crisp ways to transform to and
from phrases and language identifiers. I mean, is it
UseCamelCaseInPHP, or UseCamelCaseInPhp?
As cute as Ruby on Rails pluralizer is, it's also a source of
defects. The CamelCaseSelfishMeme has blinded people to the
TrueSemanticsOfCapitalization and the_simplicity_of
$token=str_replace(" ","_",$phrase);
-----------------
At the moment, for instance, I'm designing an object model where
several PHP objects define various behaviors of a metaobject that lives
in a relational database. If "X" is the name of the metaobject, these
could be
type_of_X,
instance_of_X,
X_controller
Now, I suppose I could call them all
X_controller
X_instance
X_type
maybe that's good, but I don't want that decision coupled to the
way I want the class files organized in the project tree. Personally I
find CPAN projects hard to read and navigate because the naming
convention enforces a sub-optimal code organization. (Not to mention
the ususally useless javadoc documentation in CPAN projects that means
the number of non-comment lines per average editor screen is about 1 or 2.)
Mind you, I could change my mind entirely if there was toolset
support that (i) wiped away the difficulties, and (ii) reaped benefits
from a fixed code organization, the way that Eclipse/Java does.
More information about the talk
mailing list