Minimizing Overhead for PHP Engine Reads

[Guest]

Hey folks,

 

I've developed a framework with an impressive number of classes in their separate class files.

 

In addition, I've included a setup & install script that merges each package of class files into a single file, for speed's sake, and changes all the include/require calls to reflect that change.

 

Now I'm thinking of alternatives.

 

I want to make a class that manages the Packages; following the registry model. Classes will install a classpath and classname into a global Package registry, and when it is needed, __autoload will load that class from the package registry.

 

Now, while I'm doing this, I want to ask: is this a reasonable pursuit? Or am I overestimating the amount of overhead is involved in including/requiring new files?

 

Anything helps, thanks!

 

EDIT:

Also, any ideas on how I can incorporate name classes without having to impose a naming syntax? For example, a core class called ServerConfig might be in the registry, and a 3rd party may install their own ServerConfig class using this package registry system.

 

Overwriting would obviously be quite dangerous; currently the only idea i have in mind is a priority boolean system, classes flagged true cannot be overwritten.

 

(just need a good place to bounce off ideas)

[trq]

Now, while I'm doing this, I want to ask: is this a reasonable pursuit? Or am I overestimating the amount of overhead is involved in including/requiring new files?

 

Autoloading required files is of course the way to go. Theres no point poisoning your namespace with classes that aren't ever going to be instantiated for that request..

 

Also, any ideas on how I can incorporate name classes without having to impose a naming syntax?

 

Without a naming syntax? Theres always going to be the chance of collission. Whats wrong with following the way pear / zendFW do it? eg;

 

A file within...

 

Foo/Boo/Bar.php

 

would contain the class Foo_Boo_Bar().

[Guest]

@thrope

Good to hear clarification; about the pear/zendFW syntax, this is just me being picky, but I feel it makes my code ugly. I like the idea of abstracting the framework from the programmer, so he won't have to worry about classpaths, for one.

 

Especially in the case that the structure of the package library changes.

 

For internal classes, the suggestion is more than perfect, and is in fact what I do already. But for public ones, well... take my static library of php function wrapper classes, for example:

 

lets say:

Type::isInteger($value);
String::replace($haystack, $search, $replace);

 

I believe they look rather intuitive as is, and while it doesn't fit as perfectly as is_int() or str_replace() into a length of code, I feel the alternative would be horrific:

 

System_Core_Type::isInteger($value);
System_Core_String::replace($haystack, $search, $replace);

 

Imagine using that in a function that normally has 2, 3 or 4 string functions per line? Messy...

 

***

 

Maybe my "aesthetics" is just an obstacle i need to get over, but I am thinking about usability for other developers.

 

But yes, this does increase the chances of name clashes.

 

And that's where this packager comes in, I can have it scan the packages directory and input all classes into a large array (which would be cached).

 

// extensions not present in the core library are added like so:
SystemPackager::install('MissingClass', 'Packages/Foo/Bar');

function __autoload($classname)
{
       SystemPackager::load($classname);
}

// elsewhere
$mc = new MissingClass();

 

Hopefully I'm not just hopelessly stubborn and wrong!

 

Plus, I don't know if I want to cycle through ~350 classfiles to rename my classes XD