TalkPHP - Speed vs Ease of use

TalkPHP (http://www.talkphp.com/forums.php)

- Advanced PHP Programming (http://www.talkphp.com/advanced-php-programming/)

- - Speed vs Ease of use (http://www.talkphp.com/advanced-php-programming/2896-speed-vs-ease-use.html)

Speed vs Ease of use

I have a tad of a problem, well not a problem more of a fork at the roads and I'd like all yours opinion.

The issue at hand is whether to use __autoload to semi handle my framework or use my own construct function which looks like this

PHP Code:


		
			
public function __construct($aClassReject = array()){



            $inc = get_included_files();



            $dir = str_replace('\\','/',dirname(__FILE__));



            for($i = 0;$i <= count($inc);++$i){



                if(strstr($inc[$i],'.class.php') and !strstr($inc[$i],'core.class.php')){



                    $className = str_replace(array($dir.'/','.class.php'),'',str_replace('\\','/',$inc[$i]));



                    if(!in_array($className,$aClassReject)){    



                        $this->classArray[$className] = (is_array($aClassReject[$className])) ?

                                        new $className($aClassReject[$className]) :

                                        new $className;    



                    }



                }



                unset($className);



            }



            



            



            //now that all classes are activated...check for their dependancies if any



            foreach($this->classArray as $key  => $val){



                $this->__fetchDep($key);



            }



        }

The issue is with __autoload I'd need to activate the classes first where as with the above function I just include the files.

I hope I'm making sense, I'm just kinda wondering what choice would be the best to go with.

Pardon me as this isn't going to be much help to your actual question, but what exactly is going on with that __construct()? I've been going over it trying to figure out exactly what's going on, and it seems to me that you're going through a list of files that have been included, instantiating the objects from that file, and then unsetting them again immediately afterwards?
-m

I guess my documentation sucks, but for the most part your right.

$className isn't an object - it's the class's name, extracted from the file.

$this->classArray[$className] is the actual object.

unset($className) that part is just cleaning up, I forgot to add in the other variables at that point.

--edit: Now I see why the documentation sucks, there is none.

Oh! hahah, no your documentation doesn't suck, though yes it is non-existent. My eye is what sucks, I thought you were creating new objects then destroying them immediately after, I glazed over the fact that you were just unsetting the variable holding the class name, not the object itself. So, let me try this again... when ever this construct is called it finds the list of files you've already included, and loads a new object into existence for each of those files that is a class (*.class.php). Interesting way to go about it.

Have you heard of the registry pattern? Check this out: http://www.talkphp.com/advanced-php-...y-pattern.html

I use a version of it that automagically includes the file if necessary, so instead of including all the necessary files at the top of my script, anytime I call my load() method, it checks to see if it's in memory, and if not, includes it. Ala,

PHP Code:


		
			
/**
 * Adds a new object instance of the specified class to the
 * static registry library, and returns a reference
 *
 * @access public
 * @static
 * @param  string $szModule The module the specified class belongs to
 * @param  string $szClass  The name of the class
 * @param  mixed  $mArgs    Arguments to be passed to the object, can be a string or an array
 * @return object Returns an instance of the specified object from the registry library
 */

static function load ($szModule, $szClass, $mArgs=null) {

    $szFilename = PATH_TO_LIB."{$szModule}.{$szClass}.php";
    $szClass    = "tuatara_{$szModule}_{$szClass}";

    if (!file_exists($szFilename)) throw new Exception("Library file cannot be found.");

    if (!class_exists($szClass)) include($szFilename);

    if (!array_key_exists($szClass, self::$_registry)) {
    
        if (is_array($mArgs)) {
            $pReflect = new ReflectionClass($szClass);
            self::$_registry[$szClass] = $pReflect->newInstanceArgs($mArgs);
        } else {
            self::$_registry[$szClass] = new $szClass($mArgs);
        }
    
    }

    return self::$_registry[$szClass];

}

Works beautifully.
-m

Well I was thinking of wrapping the entire thing up into a singleton object, you load the object and it'll then in turn load each included file - when ever you call it again it just gives back the copy of itself already in memory.

That's how I wound up with the registry. I started with the idea of the singleton, but I didn't implement it properly (didn't make each class with a private constructor and it's own getInstance method), I figured it made more sense to have one central method that called any module I wanted, so while I thought I was implementing a singleton I was actually building a registry. I just didn't know the name of it at first.

If you notice the registry does the same thing very nearly, it stores objects in the static var $_registry and calls them back from there when additional requests for the same object are made. I'm hardly a pattern expert, so I don't know what's truly best for a given situation, I just like this way, it hasn't given me any trouble performance wise whatsoever and it provided me with a clean way to build my organizational structure and load objects as I needed them.
-m