Re: Re: [binarycloud-dev] FW: lets talk "metapear" - politics aside:-)

>> could be done to make it a lot faster. >> > Actually I think if we find a nice solution to separate metapear into > packages then I think metapear can very well compete with PEAR DB in > performance (I think PEAR DB probably has some overhead with their result > object which if I got tomas right is not something that really did much for I agree. Though I think there will always be a (small) speed hit for the proper datatype abstraction/translation. Which is of course fine with me because it makes my applications portable in the real world > Obviously seperating everything into packages is very easy. But I would like > the including to happen automagically somehow :-) Yepp! :) >> Oh nevermind I kept reading, I get it. A BC metabase wrapper and a BC PEARDB >> wrapper? >> > Yeah exactly. Allthough metabase does not really not a wrapper .. just a > slightly modfied metabase_interface.php Got it. >> Do what you think is right, check in once and a while, and if you happen to >> miss something we'll fix it - a lot of people will use this :) >> > thx :-) one thing to keep in mind though: my strengths are mostly in design > and not so much in php coding as I am not all that experienced in php > coding. So even though my ideas might be sound, my code could maybe use an > experienced hand (if only to use php to the max). Well, even better. I am the same way in most cases, I am a system designer not an algorithms person - so do what you can and I'm sure the code will evolve _very_ fast. We just need to get to the point where it's usable and functional so people will start using it in production. > Anyways I also think that the pear error handling (with their error code > abstraction) is the way to go (allthough Manuel does not quite agree there). I disagree with him - without having seen the argument: in this case I'm happy to flush BC down the toilet to get serious error handling in a common framework. if you want a new building you need to knock parts out, error handling is one of them :) > But I guess that had to happen anyways if "metapear" was to be included into > PEAR (which to me is the main reason for all of this). Yep! Pear Error handling is well designed (ok I have a couple gripes) and we should all use it :) _a