How is Solar different from PEAR?

Regarding the latest release of Solar, Atrus asked: “How is this significantly different from PEAR?”

It’s a good question. Let me outline some of what I think are the major differences. Please note that with maybe one exception, none of this is intended as criticism of PEAR, only as description. You can figure out for yourself where the criticism lies.

  1. As Atrus noted, Solar is built from the ground up for E_STRICT compliance in PHP5, which makes it incompatible with PHP4.
  2. Having said that, Solar is very much like PEAR in concept, in that one of its goals is to be a class library providing common web application functions: error handling, user authentication, querying SQL sources, OR mangement, and so on. However, Solar differs from PEAR in execution of that concept:
    • All class constructors have identical parameters (a single associative array).
    • Almost all Solar classes are extended from a single base class. The base class is relatively light and provides common functionality such as error generation and localization string handling. This means that all Solar classes have localization built in from the start. (Some classes are not extended from the base class; typically, these classes are collections of static methods.)
    • The classes are much more consistent with each other because they are the product of one coder (your humble servant).
    • The code is better-commented, easier to read, simpler, and more straightforward than most of what is found in PEAR.
  3. Solar is quite different from PEAR in that it is also a framework.
    • Yawp was my one attempt at building a straightforward and comprehensible foundation for rapid application development out of PEAR components. While Yawp is moderately successful at this, the inconsistency between PEAR classes makes it necessary to custom-code the “glue” between those classes so they can interoperate. With Solar, the classes are all so similar in implementation that it is much easier to make them interoperate.
    • As a framework, Solar has a consistent and extensible configuration mechanism that is identical for each class in the system; PEAR does not have such a mechanism.
    • Solar provides built-in methods for safe retrieval of user-provided variables and configuration values; PEAR does not.
  4. Solar provides mid-level independent application components out of the box (these are called Solar Cells). For example, there is a universal tagging mechanism, a combined comments/trackback storage system, a bug-tracking entity, and so on. Combining these components with a little procedural glue (e.g. in a controller action) gets you a lot of good functionality in a much less time. PEAR has no such unified component mechanism that I know of (happy to be proved wrong here).
  5. Solar comes with useful applications out-of-the-box (a bug tracker and a bookmark system) with more on the way, such as blog and wiki. With the one exception of phpDocumentor, PEAR does not. You might say that the “AR” in Solar is actually true. πŸ˜‰ In this way, Solar might be more like Horde than PEAR.
  6. The communities are very different. PEAR is a mishmash of developers with their own goals and desires, driven by a voting system for new packages, herded like cats by an unelected Group that prefers to force collaboration under a rule of seniority, and with various (probably unfixable) flaws in the social norms; in other words, it is much like elitist democracy or mob rule under appointed oligarchy. Solar is more like beneficent dictatorship where the main rule is “be nice.” πŸ˜‰
  7. Last but not least: PEAR has been in place for a few years now, and Solar is very young (first release was only 2 months ago). If you want to get in on the ground floor of a growing community of PHP5 developers and make a difference in a new project, this might be the place for you. Sign up for the mailing list at the Solar home page:
Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving your codebase, all while keeping it running the whole time.

14 thoughts on “How is Solar different from PEAR?

  1. Hi, Lukas —

    Although YaWiki is in a little hiatus right now, it is *not* going away. I depend on it myself. However, it it likely to remain a PHP4 (non-strict PHP5) application, along with Yawp.

    A second wiki app for PHP5 under Solar is one of my next projects, though; maybe I can work the two in parallel so good ideas one will port to the other.

  2. Quick question: why do you use an associative array for construction parameters?

    One of the useful things about Zend’s Studio is that it pops up a list of parameters when you type the ( at the end of a function name. Very useful to people who have memory blanks for parameter ordering like me! Though I suppose if the phpdoc block above the constructor lists the possible keys, all is well πŸ™‚

  3. Hi Paul,

    Your post is very interesting. It helps me to understand more on Solar. But one thing I am confused on Solar is that how MVC design applies in Solar as a whole (

    As I learn from your post, Solar is being developed to be a all-in-one PHP5 web applications frameworks (with some ready made appz), not only as a MVC framework like Struts in Java ( or Mojavi, phpMVC in PHP.

    Could you have one more question: Could Solar architecture deal with a multi-language sites?

    Thanks for your time.

  4. Associative array as constructor parameter, eh?

    Anyways it’d have been great if PHP support named parameters… I guess it’s somehow consistent with the PHP “spirit”… (like Smarty supports template functions with named parameters)

  5. How about Savant?

    I’m using Savant3 by the way as of today, frustrated by my inability to detect what’s so f*cking wrong with my Smarty templates when they died without any f*cking reason… (it’s much easier to fix my script when it displays something rather than dying without explanation) Maybe it’s a bug within Smarty (or its compiler), but if a template engine is so complex it has a bug, well you know what you have to do…

    Anyways, forgive my babbling… I noticed Solar uses it’s own “template engine” (that is, pure PHP) rather than Savant (which happened to be developed by?)… may I know why?

  6. Hi, Hendy — quick note: the apps that come with Solar *do* use Savant3 as their template system. I’m not eager to bundle a template system with Solar yet, other than perhaps just an interface class so that all Solar apps can have an expected interface to templates. Template systems are objects of religious devotion. πŸ˜‰

  7. Hi, Rob — I use an assoc array as the only constructor parameter for a couple of reasons.

    (1) No need to remember the order of params, they’re all named.

    (2) More importantly, it is much easier to pull default values from a config file that way; Solar.config.php contains a default array of constructor values for a given class, then you call Solar::object(‘Solar_Class_Name’) to instantiate that class with the default values from the config file, or Solar::object(‘Solar_Class_Name’, $config_array) to provide your own constructor values.

    And yes, the docblocks all have the keys listed with expected type and a short description. πŸ˜‰

  8. Hi, pcdinh —

    one thing I am confused on Solar is that how MVC design applies in Solar as a whole (

    As I continue to work on it, I am beginning to see that Solar is best described as three related blocks:

    (1) The foundational class library and the unifying Solar.php class,

    (2) the Solar_Cell component packages, and

    (3) the Solar_App applications.

    MVC doesn’t really come into play until we get to the Solar_App level, in that the models are generally composed of Solar_Cells, and the views are generally Savant3 templates, and the controllers are extended from the Solar_App class. (Yes, I know this is confusing to read … I’m working on new-user documentation to make it more clear.)

    As I learn from your post, Solar is being developed to be a all-in-one PHP5 web applications frameworks (with some ready made appz), not only as a MVC framework like Struts in Java ( or Mojavi, phpMVC in PHP.

    Yes, this sounds like an accurate description.

    Could you have one more question: Could Solar architecture deal with a multi-language sites?

    Yes. πŸ™‚ A Solar_Locale class is instantiated as a shared object in the Solar foundation class as Solar::$shared->locale.

    The Solar_Base class, from which almost everything else is extended, keeps a reference back to that shared locale object; all you need to do in your extended object is call $this->locale().

    Finally, language translations for each class are bundled in each class directory under “Locale/” … when you call Solar::$shared->locale->setCode(‘en_EN’), that switches all the locale strings to the English translations to use “*/Locale/en_EN.php”. (I am actively looking for translators for languages other than English.)

    Hope this helps, let me know if it does not.

  9. Oh, so now I see why error messages in Savant3 are internationalized.

    It’d be helpful though to have these messages sprintf-ed somehow… I mean, it’s not very interesting to have a “Template plugin error” message and not knowing which plugin caused the error or any other explanation.

  10. Whew! I posted on the exact same minute when Mr. Jones posted!! Too bad these isn’t the second part there, otherwise I could’ve measured how I was bonded to him πŸ˜‰

    Anyways, while noticing the “blocks in Solar” I guess you may as well some time in visualizing the overall architecture of Solar in a simple block diagram. It’d be cool πŸ˜‰

  11. Why comparing Solar with PEAR?

    Since Solar is a framework, I guess it’s more suited to be compared to other frameworks like Horde, Jaws, Midgard, Sitellite, Binarycloud, … (too numerous to mention, but some [old] frameworks I’ve noticed and the reviews are available at )

    I think of PEAR as a class library, some parts of it may have dependencies, but they’re not integrated (which usually means they’re not coupled). I’ve noticed a PEAR package with a Solar-ish spirit named “Gadgets” (IIRC).

  12. […] I can only agree — it was like when I got emails asking “how is Solar different from PEAR?”. The three (PEAR, Solar, Zend Framework) are not really that different architecturally; Solar owes quite a lot to the PEAR standards for class naming, directory hierarchy, coding standards, and so on. Each of the projects has its own dependencies and idiosyncrasies, but if you know how each project works, then you can work on combining pieces from them effectively. The key differences are in the implementations, the little tweaks each makes to the related design patterns, and the society/culture/support-group that grows up around them. (That last part about culture is too often neglected; I like to think the Solar social norms are more approachable for anyone with a learning/mentoring attitude toward programming.) […]

Leave a Reply

Your email address will not be published. Required fields are marked *