Posted: Sun May 13, 2007 2:58 pm
I like d11twq's analogy the best: implementing __autoload() means you are adopting Java's style of class management.
A community of PHP developers offering assistance, advice, discussion, and friendship.
http://forums.devnetwork.net/
If it was named "class_available" it might be more clear. It is supposed to depict if the class asked for is available - be it loaded or autoloaded.Ambush Commander wrote:While I won't pass judgment on the new behavior, I have certainly been bitten by the autoloading behavior of class_exists.
Loading the class as in including the file in which the class is contained? Or is there more to it than that?arborint wrote: Foo.phptest.phpCode: Select all
<?php class Foo { function Foo() { echo 'Foo'; } }It will output:Code: Select all
<?php function __autoload($class) { include $class . '.php'; } if (class_exists('Foo')) { echo '1st check Foo exists.<br/>'; } if (class_exists('Foo')) { echo '2nd check Foo exists.<br/>'; }That means if an autoload function is present that class_exists() returns true if a class is not loaded -- and load the class, and of course true if the class has been previously loaded.Code: Select all
1st check Foo exists. 2nd check Foo exists.
Not more -- different. What they have done is added the autoload callback check/call to other functions related to whether a class has been loaded. Since all those functions now run the same internal check as new, they all have the ability to "benefit" (dreamscapeEverah wrote:Loading the class as in including the file in which the class is contained? Or is there more to it than that?
While I recognise your point, I have a hard time seeing any alternatives. What other mechanisms, could have been implemented to provide a similar feature?arborint wrote:My point in my comments in this thread is not that this system is not workable, nor that it might not be the best for PHP. My point was that we may never know if the alternatives were better because this system evolved from a focus on what was easy to implement in the engine, rather than what might be the best design or promoting practice in PHP OOP. It was my opinion that the reason this happened is that they developers know a lot about the engine's internals, but are pretty provincial in their knowledge of OOP.
If there's no autoload, class_exists(Foo) returns false and new Foo raises a fatal error. An adequate design solution would be to throw the normal catchable ClassNotFound exception instead. Hopefully this is going to happen in php6, and autoload will be deprecated just like other "cool" php features: register_globals, magic_quotes etc.Everah wrote:So my next question is does PHP have a default autoloader of sorts? I mean, if you do not define __autoload and call class_exists without turning off autoloading, how does PHP interpret that?
I mention some alternatives here but I don't really have a well thought out answer. And as I have said repeatedly, autoload is a workable solution. I think Everah's questions show that it is not perhaps the clearest solution. For example, they could have followed the session system's design and had a autoload_start() function with a default autoload function that just used the current path and perhaps replaced underscores with path separators. You could then register replacement or additional autoloaders. That would have been both consistent with what people know and would have set a standard that was a baseline.kyberfabrikken wrote:While I recognise your point, I have a hard time seeing any alternatives. What other mechanisms, could have been implemented to provide a similar feature?
I my book, autoload is an all out improvement. It provides lazy loading of classes, and it decouples the filename from the code, using the class.
Can you give an example?Ambush Commander wrote:The definition of the __autoload() is, itself, "turning on" autoload. Otherwise, one acts as if it doesn't exist.
I think that's part of the problem: if you have a library that uses class semantics as if there was no autoload, and it gets used in an application that has __autoload, you'll have problems. I did.
Code: Select all
<?php
$object = new Class_Objectifier();
?>I think the thing that you are not getting is that there is now autoload function -- you supply the function to load classes. So if you used the simple autoload function I posted:Everah wrote:Ok, I think I am getting autoloading. Example:If the code that contains the class Class_Objectifier has not been included, or that class is not yet defined within the current scope, PHP will invoke autoload and attempt to find the class file based on what is in __autoload(). If it can find it using __autoload() it will include it and instantiate it. If it cannot find it using __autoload(), then it craps out completely and squawks.Code: Select all
<?php $object = new Class_Objectifier(); ?>
Code: Select all
<?php
function __autoload($class) {
include $class . '.php';
}All the SPL autoload functions do is allow multiple autoload functions. This is because there is only one possible function named "__autoload" so if I write a library that uses "__autoload" and the application is already defining "__autoload" then there is a name clash. The SPL functions get around the name clash.Everah wrote:Not how does this work in conjunction with spl_autoload_register()?
These methods come in really useful at times. I use __get() and __set() in my abstract View component (just like many others do), but I also provide setVar() and getVar() in the View too. They're just convenience methods really.arborint wrote:I have the same problem with __get()/__set()/__call() -- they are solutions, but there are many other ways to solve the same problems that might promote better practices in the long run/big picture. Or maybe not and I am just full of it.
I think arborint's point was that the implementation is sketchy. C#'s "properties" are a much nicer implementation of basically the same functionality.d11wtq wrote: These methods come in really useful at times. I use __get() and __set() in my abstract View component (just like many others do), but I also provide setVar() and getVar() in the View too. They're just convenience methods really.