Where do you keep your functions and classes?

[Mandibal]

Which of the three methods did you use for the parameter configuration?

I actually use 2 of the 3. I use php.ini for the include_path and session.save and upload_tmp_dir settings and then I use an initialization script but only for defining constants for the different classes.

define('DB', $LIB_DIR.'database/database.class.php'); 

The initialization script I keep in the conf folder of the repository (which is in the include_path) and so I can call it from any site. I usually just call the initialize.php in a siteName.conf.php file which is site specific.

[lastcraft]

Hi...

...regarding abstract classes (which is where that 20+ can come from), either as convention in PHP or declared in PHP5, use them only when you really must, in PHP.

A lot of abstract classes are a sign that the design is woolly and nobody is sure what is going on and so nobody wants to refactor them out. This seems to happen when there is only one designer on a project and nobody else is much interested. The lone designer gets into a tangle and everybody else goes into nine-to-five mode and just works around it. Ironically they can be a sign of poorer communication, not better.

If code has no purpose other than to instruct other developers, don't bother.

Except that instructing other developers is extremely useful if you have imperfect means of communication. A unifying abstract class can save you a bunch of repetitive unit tests, give you a clear mocking point and communicate a shared structure for a project. I certainly would not ban them, and certainly not on performance grounds.

As PHP source code is generally always available, use well placed comments instead. And the more I think about interfaces, in PHP5, the more I think they're an expensive luxury.

The contract style of development and unit testing are complementary. You can save yourself quite a few unit tests with a few good interfaces and it is much easier to refactor such code - fewer tests to rewrite. I like the fact that they are optional in PHP5 as they give a lot of power. If sprinkled liberally they will pile on a suffocating list of restrictions. Small numbers of evolved interfaces that express the design are my ideal.

Comments are a poor compromise. It's an odd thing that the code will get refactored, but the comment will probably live on to become misleading. For some reason developers hardly touch each other's comments; the opposite of what's needed.

WACT is already reaching fairly significant complexity and has four developers collaborating over the wire. Generally there's little confusion and I can't think of an example where a dumb abstract class would have helped, where there was.

I am impressed, but...

With that level of communication, and a high level of design will, you shouldn't need much supporting scaffold. I am not sure other developers perusing the code for their own ends will be so pleased. How much are you self compensating for the lack of interfaces with comments, tests and naming conventions on the related classes? This doesn't make any difference in PHP4, but when PHP5 enforces interfaces I think you will find them very useful.

As for protected and private methods, if your design has lot's of delegation then you tend to find that public methods are all you need. The problem occours when you are using inheritance as a form of developer interface, typical in frameworks. Even I have to concede that this can be useful sometimes.

Regarding the original post:

As for organising the file structure, I tend to view the class files as packages by personal preference. This means a bunch of related classes in one file, say 5 classes in 400 lines of file as typical. I have to load fewer files in the editor this way.

At work it's usually one class per file, except for bunches of strategies, states or errors which tend to be grouped. Because of their numbers this averages out at just over two classes per file (a misleading figure because most are just one).

I think just choose any system that is not too extreme.

yours, Marcus

[Toly]

I actually use 2 of the 3. I use php.ini for the include_path and session.save and upload_tmp_dir settings and then I use an initialization script but only for defining constants for the different classes.

define('DB', $LIB_DIR.'database/database.class.php'); 

The initialization script I keep in the conf folder of the repository (which is in the include_path) and so I can call it from any site. I usually just call the initialize.php in a siteName.conf.php file which is site specific.

If you would be on a shared server and didn't have access to the php.ini file, would you use .htaccess or the initialization script?

The initialization script is definitely nicer since it doesn't depend on the server, but since the script needs to be included on every php script that requires access to the libraries, could that be a problem from a performance point of view?

[Toly]

As for organising the file structure, I tend to view the class files as packages by personal preference. This means a bunch of related classes in one file, say 5 classes in 400 lines of file as typical. I have to load fewer files in the editor this way.

At work it's usually one class per file, except for bunches of strategies, states or errors which tend to be grouped. Because of their numbers this averages out at just over two classes per file (a misleading figure because most are just one)

How do you organize them?

[Mandibal]

If you would be on a shared server and didn't have access to the php.ini file, would you use .htaccess or the initialization script?

The initialization script is definitely nicer since it doesn't depend on the server, but since the script needs to be included on every php script that requires access to the libraries, could that be a problem from a performance point of view?

Personally I'd use the .htaccess for the inlcude_path part at least and the initialization script for defining constants. This makes it very conveniant and easy to use:

include_once('initialize.php'); 

where ever you want w/o worrying about the path to the initialization script. Then using my previous example of a define for the database class:

include_once(DB); 

I have about 20 defines in my initialization script and on average I might use 2 per page for including the classes I need.

[Toly]

Personally I'd use the .htaccess for the inlcude_path part at least and the initialization script for defining constants. This makes it very conveniant and easy to use:

include_once('initialize.php'); 

where ever you want w/o worrying about the path to the initialization script. Then using my previous example of a define for the database class:

include_once(DB); 

I have about 20 defines in my initialization script and on average I might use 2 per page for including the classes I need.

That is a good example... combining both methods is the best way.

Thanks.

[Mandibal]

I figured it might be interesting to explain my entire config file/include file method. One of the reasons I've settled on this method is for ease of moving between a development server and a production server.
1. I have a repository directory (as already outlined in the article). The initialize.php script is for use with this repository code.
2. I use 2 configuration files for site specific stuff. These are stored in the conf directory of the repository.
a) File one i call sitename.base.conf.php and it contains the call to inlcude the intializaton script as well as server (production vs dev) specific base paths and urls. I actually have 2 versions of this file which i dont change once created becaue they only contain 3 pieces of information. One is for the dev server and one is for production server.
b) The second file is called sitename.conf.php and it first calls sitename.base.conf.php and then it defines constants specific to the site classes, directories, templates etc. Once i start developing the site I only alter this file so I can copy it to both servers w/o making server specific changes (base paths or urls).
3. I call only sitename.conf.php from all pages in the site. Because this file is in the repository/conf folder I can still just use include_once('sitename.conf.php');

So for a dev server I have:
initialize.base.php
initialize.php
-sitename.base.conf.php
-sitename.conf.php

The base files are dev/production specific and dont change. I make changes in the conf and initialize files because they are the portable files.
example intialize.base.php:

$reposPath = "/Library/Apache2/repository"; 

example initialize.php

include_once('initialize.base.php');

$LIB_DIR = $reposPath.'/libraries/';

define('DB', $LIB_DIR.'database/database.class.php');
define('SESSION', $LIB_DIR.'session/session.class.php'); 

example sitename.base.conf.php

define('BASE_DIR', '/Library/Apache2/htdocs/sitename/');
define('BASE_URL', 'http://sitename/');
define('LIB', BASE_DIR.'lib/'); 

example sitename.conf.php

include_once('initialize.php');
include_once('sitename.base.conf.php');

define('SITE_USERS', LIB.'model/users.class.php');
define('TABLEDAO', LIB.'dao/tableDAO.class.php'); 

And finally in any given page:

include_once('sitename.conf.php');
include_once(DB);
include_ocne(SITE_USERS);

//blah blah do something clever with all those wonderful classes 

HTH someone

[Toly]

That's interesting, but I didn't understand why you need the initialize.base.php file or where you have it on your repository directory.

It also seems that you are storing your classes outside the repository directory, why?

[Mandibal]

the initialize.base is for the same purpose as the sitename.base.conf file. It has the server specific configuration stuff in it. On the dev server the initialize.base.php has path variables that are different than the production servers path variables so I need a different production server base path. Once i've created the base files I dont change them and I dont include them in file I copy from the dev server to the production server. I only transfer the initialize.php and the sitename.conf.php files.

I'm not storing all my classes outside the repository. Just the site specific classes. Any reusable code/class goes in the repository so its available to all site but for site specific classes like dao's and domain logic specific to a particular site I like to keep these in a lib folder in that web site. This way when I'm only working on site specific stuff (classes/styles/templates/etc) I only have to copy the site folder, not the repository folder as well. The repository is outside of the htdocs folder like the article recommends.

I'm not even 100% sure how effective my entire methodology is or if its really the best method...but so far I've found it works very well. Especially for transfering from one server to another and not worrying about server specific paths and urls getting borken.

[HarryF]

How much are you self compensating for the lack of interfaces with comments, tests and naming conventions on the related classes?

True - I guess it's developing as if we had interfaces. Aside from the inline documentation, we're also having to make an extra effort with examples, the WIKI and so on. The "social experiment" will be if, through lack of interfaces and static rules in the code, we make more effort to flag things, perhaps resulting in more useful information.

Would be interesting to research what strategy developers employ when getting to grips with 3rd party code. My guess it would be, in general, something like;

1. examples
2. API docs
3. source code
4. Any other documentation (including tests)

If success is met early, later steps probably won't happen. If there's a high risk factor associated with using the library, perhaps source code examination will probably happen earlier. Guess if they only work with examples (and perhaps out of date documentation), interfaces and other static rules become useful. Lots of guessing...

[lastcraft]

Hi...

Hey, I feel another list coming on!

1. examples
2. API docs
3. source code
4. Any other documentation (including tests)

Also how about (in no particular order)...
5) Guessing method names (with IDE help) and parameters.
6) Tutorial
7) Pair programming
8) Magazine articles
9) Book chapters

My own preferences are 6 or 9 followed 4 (tests) day to day, but I reckon we will get as much variation here as we will from how the source code is organised. Anyone want to start a poll?

yours, Marcus