From: alex b. <en...@tu...> - 2001-07-11 03:47:35
|
> Which brings up a question. Why selectively use some PEAR classes for > things, and not others. For consistency, would it not make sense to Because some pear classes are mature and good, others aren't. for example, Pear_error on the whole is quite good. Pear DB isn't. > utilize all new PEAR functionaliy in a sort of wrapper that speaks to > the managers? This of course would only depends on MetaBase having PEAR is (and will be considered as such in bc) a set of libraries. PEAR stuff will be included by core and modules as needed, for caching, error handling, and anything else people find that they like. > features that binarycloud would ultimately depends on. QuerManager depends on Metabase. It is a superior abstraction layer, which I have no intention of switching. I have used Pear DB. I don't like it. :) Of course, you are welcome to use it in your modules instead of queryManager, but you will lose all of the benefits of using QueryManager, of course.. > I personally > would rather see a more suitable/simple wrapper for the database calls, > and extend the extra features of metabase into external tools. I actually would as well. But as it happens, it's in one package, and it's better than anything else I have seen. To boot, it's mature, and fast. > Perhaps this is where I can help contribute once I have more nerves to > play with. Right now, it's only bones and muscle. =] > > a long overdue thanks to alex, for this great incentive. I'm actually going to work on "general" PEAR integration this week, and start distro'ing the bits of PEAR we use in binarycloud/ext. PEAR will be included at Init, so you'll have complete access to the Pear libs. -alex |