[prev in list] [next in list] [prev in thread] [next in thread] 

List:       nyphp-talk
Subject:    Re: [nyphp-talk] php autoloading
From:       Paul A Houle <paul () devonianfarm ! com>
Date:       2009-01-16 19:44:51
Message-ID: 4970E3B3.5030900 () devonianfarm ! com
[Download RAW message or body]

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.
_______________________________________________
New York PHP User Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk

http://www.nyphp.org/show_participation.php
[prev in list] [next in list] [prev in thread] [next in thread]