So:

$a = new TheInstantiatedClass() # in code

…where the class def looks like

class TheInstatiatedClass extend TheCoreClass
{
}

If you want to override TheCoreClass, the rule is that you do it by changing the “extend” clause and allow the auto-load stuff you explained above to take care of finding it.

It’s more of a BFMI (Brute Force, Massive Ignorance) approach, but has simplicity on its side and doesn’t mess around with what PHP calls metaprogramming. The downside is that it makes it impossible to use both unmodified and modified classes at once.

$class = ‘MyClass’;
$object = new $class();

…but you can’t define a class with a variable:

$parent = ‘MyClass’;
class SubClass extends $parent { /* … */ }

It’s the latter case that gets in the way for VuFind… but if you don’t need to do that, you can probably get away with using variables.

The way that the record drivers and ILS drivers currently work is relatively straight forward when it comes to modifying methods but here we have the option of naming the new php class we wish to call. It would be pretty tedious if we had to do that for every custom class!

Of course, the benefits of the change are much cleaner and non-conflicting code so in essence, it’s a no-brainer.

As you point out and as Jonathan says, I see the code eval() and I immediately think of hell and damnation but as long as one considers the advice given by Uncle Ben to Peter Parker “With great power comes great responsibility”, I’m sure I can get over that.

I think how you’ve done is probably the neatest way to do it in PHP.

Two things made me eventually reject that idea, though:

1.) It puts its footprints all over the code — lots of extra variables everywhere, and potentially extra calls to populate those variables every time you try to construct an object. The approach detailed in this post is a lot more seamless.

2.) It doesn’t work well when the core code already has class hierarchies in it. In PHP, you can’t instantiate classes using variable names without using the eval() function (unless I’m missing something). This means that there’s no easy way to make a subclass extend a variable parent class. Since VuFind has a lot of base classes that people might want to modify without necessarily changing their subclasses, I don’t think the variable approach is workable. However, again, the approach detailed in this post works around that problem, as long as your classes extend parent classes from the “Extensible_” namespace rather than the “Core_” namespace.

I can see how that approach might be appropriate in a less complex project, though!

Man, I wouldn’t want to try and implement that in PHP either. PHP’s OO facilities are… not my preference to work in.

You might want to check out Xerxes (the Metalib front-end), Xerxes does a pretty good of keeping local and core code seperate, but Xerxes is much simpler and less flexible software. It basically lets you specify an ‘action’ class for each action (basically each URL path endpoint) in an XML config file, where by default they are the core ones, but you could use your custom ones. But there’s no way to substitute PHP object classes more granularly than that.

Xerxes’s ‘view’ layer, for better or worse is all XSLT, and it’s set up so your local XSLT files are loaded in dynamically on top of the core ones, such that you can over-ride the XSLT on a template-by-template basis. (That’s an individual XSLT template; designing the core XSLT to put these templates at the right granularity is the trick).