Suppose you are building a web application that is going to be a packaged product one day, one that users will want to be able to extend and customize.
It comes with
I'd go with using the constructor of the core class to determine the user class to load, and then implement a factory method in the core class to generate instances of the user class. By making the constructor of the user class protected, and having the user class extend the core class you can be sure that code elsewhere cannot instantiate the user class.
C.
Why don't you follow the approach as used by Propel? You generate your base classes and already provide an empty User class (extending the base class) where your users can put their overrides/specific implementation details, and in your code you always refer to the User classes. So basically you just use the inverse of the logic you described.
If the explanation above isn't clear, check out http://propel.phpdb.org/trac/wiki/Users/Documentation/1.4/QuickStart#a6.UsingtheGeneratedSQLandOMFiles and generate code for a small database. The base classes are in the om folder, the (by default empty) user classes are in the root folder.
You could have a loader class that will decide which class to instance:
Loader::instance()->load('Frontend')
I think it's more complicated with a single filename when you want to use inheritance as well. Basically class user_frontend extends core_frontend
has to know where to find both classes. Both must be included.
If you just want to do new Frontend
you could use PHP5.3's class_alias to point Frontend to the main class to use. Below 5.3. you could use a ServiceFinder, that knows how to map Service Names to Classes and then get the Frontend with $service->get('frontend')
or use a Dependency Injection framework.
Edit I removed the Loader code given before, because it was suffering from exactly this problem.
I would implement hooks in the core, so users dont have to hack the core, but are still able to extend the core using hooks