On Mon, Feb 13, 2012 at 09:24:38AM +1100, Elbert F wrote:

> Hi Simon,
> I think you're right that I may be abusing the constructor a bit. I'm going
> to follow your suggestion and split it up into smaller functions. I'm also
> thinking of moving the set_error_handler and spl_autoload_register
> functions to index.php where Swiftlet is bootstrapped so they can be
> changed.

I didn't look thoroughly at your code (though, if the respondent's
perceptions were correct, I'd have to agree with his prescriptions for
improvement). But I wanted to make a comment about autoloaders, since
you mentioned it.

My philosophy, since autoloading was introduced, was that it was a cool
way to avoid having a lot of complicated file inclusion calls all over
the place. Just tell the autoloader function where different types of
files were located, and then just instantiate classes as you like. Easy.

But I recently did some work for one of these companies with a million
file internally developed framework. And at the top of each file, they'd
include a require_once() (or similar) call for each of the files which
would be called if you needed to instantiate a class from any of those
files. So rather than putting all the magic in an autoloader function,
they'd simply include the file where they knew it would be needed.
(E.g., you know you're going to be calling your Date class in this file,
so you put a require_once() call to the file that contains it at the top
of this file.)

The more I've thought about it since then, the more I've considered it a
Good Thing(tm). It makes troubleshooting existing code a whole lot
easier. I don't have to wonder what the autoloader is doing or where the
files are, on which the current file depends. It sort of obviates the
autoloader stuff, but I'd rather do that than spend hours trying to
track down which file in which directory contains the class which paints
the screen blue or whatever. (Yes, I'm aware that require_once()
introduces some latency.)

Just something to consider.


Paul M. Foster

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to