Jump to content

mkz

New Members
  • Posts

    2
  • Joined

  • Last visited

    Never

Profile Information

  • Gender
    Not Telling

mkz's Achievements

Newbie

Newbie (1/5)

0

Reputation

  1. I was hoping to find someone to give some advice. The topic isn't too advanced for you guys, is it? I can try to shorten the question! [*]Does anyone use PHP's class autoloading features? If so, what are your best practices? If not, why not? [*]If you have a library of autoloaded PHP classes, what's the best way to separate the common lib from the application lib? I considered cascading include paths (like Kohana) but that violates the principle that namespaces correspond to the physical class structure. Any other solutions?
  2. Hello, I'm new to the forum and I'm looking for advice. I use a bunch of classes in namespaces that are I'm attempting to organize for autoloading. In other words, a class called \Foo\Package\Class is loaded from the file at Foo\Package\Class.php. I'm using spl_autoload for this. (If I were on 5.2 I could be using underscore-delimited pseudo-namespaces just as well; the implementation detail isn't important) Now, I want to have multiple separate apps that use a single common library. Each app also has some classes that are local to it. How should I solve the autoloading problem? I thought of the following approach. Is it any good? [*]Try autoloading from the common class library [*]If it fails, try autoloading from the app's own local library Part 2 of the question: Within my apps, though, there are two types of classes: library ("vendor") classes that are only being used in that particular app so they don't need to be in the shared library, and app-specific classes that are the core of the app (so they, by definition, don't need to be in any shared library). I'd probably like to keep these two separate, so I'd need to add point #3 to the list above: search in the "core" class hierarchy of the local app. This gives 3 separate locations, and the problem is that they negate the advantages namespaces since there can be overlap. In which case one class will override the other during autoloading. So order of the above list would matter. And time would be wasted looking for a class in the first two places if it's more often in the third. A solution I was considering is sticking to just one central library of classes (and dumping all app-local libraries there). Then, the core classes that belong to one app would be under an \AppName namespace. I'm looking forward to some insights from the experts. How do you guys organize your class libraries?
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.