* Thus wrote Ed Lazor:
> > -----Original Message-----
> > What you can do is something like this:
> >
> >
> 1> function __autoload($class_name) {
> 2> static $_stack = array();
> 3>
>
> This didn't seem to work. The stack stuff just ends up dumping the value of
> $class_name. Also, why check to see if the class exists on line #8? Isn't
> PHP calling __autoload already confirming that the class doesn't exist?
Yeah, i didn't test the code, just throwing out some ideas :) The
class_exist() call is used to ensure that even though the was
successfully included, the class was actually defined in there as
well.
>
> I'll include copies of the two scripts below. Here's information on the
> scripts that might help explain things.
>
> The first script is being saved as Test.php. It includes a class called
> Test.
>
> The second script is being saved as test2.php. This script has a class
> called ClassDependent. It depends on the Test class.
>
> I'm trying to address two situations are being addressed here. What if the
> file Test.php is missing for some reason. And, even if the file is present,
> what happens if the file / class hasn't been loaded?
>
> In my opinion, if class Test is missing, it makes sense to know up front.
> It provides a sort of checks and balances. Otherwise, the class doesn't
> show as missing until there's an attempt to load it. I can easily see
> deploying an app without realizing there's a problem until someone happens
> to use some osbure feature that depends on the missing class.
I usually get around this solution by using require_once inside my
class definitions, for all the classes it relies on:
<?php
require_once('classes/Foo/Bar.php'); // Defines FooBar
class Qaz {
function doSomething() {
$foo_bar = new FooBar();
}
}
?>
This forces a compile error and forces you ensures that classes are
defined.
> I know that I could just create a list of files belonging to the app and
> check to make sure that they are all present when starting. It seems like
> there could be a lot of overhead in maintaining something like this. It
> also seems to make sense that you'd want classes to define their own
> dependencies for portability. What do you think?
>
> All of this kind of leads into why I'd like autoload (or some other tool) to
> indicate which class ran into a problem loading another class. In the
> examples below, it helps troubleshoot things if the error message tells me
> that ClassDependent was unable to load class Test. Hehe Having the error
> message tell me which line number would also be super cool, but maybe that's
> not possible.
If you want full control of the loading of your classes, then you
might want to use a Factory Class, that manages loading of your
objects:
<?php // Factory.php
class Factory {
static private $uses = array();
static public function newObject($obj) {
if (! class_exists($obj) ) {
Factory::$uses = array(); //reset
//include class file...
//require_once($obj);
// validate/load these classes...
var_dump(Factory::$uses);
if ($some_sort_of_error ) {
throw new Exception(Factory::errorString());
}
}
return new $obj;
}
static public function uses() {
Factory::$uses = func_get_args();
}
static public function errorString() {
// obtain proper file, line, function backtrace
// with debug_backtrace..
return $message;
}
}
?>
<?php // Test.php
Factory::uses('TestClass', 'OtherClass'):
class Test { ... }
?>
Then:
require('Factory.php');
try {
$obj = Factory::newObject('Test');
}
Of course all the above probably needs a lot of work :)
Curt
--
The above comments may offend you. flame at will.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
