Re: Re: [metabase-dev] MDB news
| From: | Manuel Lemos | Date: | Sat, 07 Sep 2002 06:11:48 +0000 |
| Subject: | Re: Re: [metabase-dev] MDB news | ||
| References: | 1 2 3 4 5 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-8910@lists.php.net to get a copy of this message | ||
Hello,
On 09/05/2002 06:20 PM, Christian Dickmann wrote:
That is ridiculous. I started Metabase in late 1998. I released it early 2000. It took a little over 1 year before I decided it was ready for release with 6 drivers. Most drivers were ready very early.Maybe you coded your code too fast. Metabase has nice features, works very well, but your code is ugly like hell. Its terribly slow, hard to
read and the API which users have to use is ugly too.You are missing my point. Metabase was mature when it was released for the first time. The goal than was to provide an API that would not change with backwards incompatibilities. That was a solid foundation for use in production environments without anything to stop it from evolving or being optimized which happened over time without affecting user applications.
I don't know where you learned to program, but programming is not a beauty contest. If you don't like the style that is just your opinion because that does not stop the code to work consistently as it is documented. Anyway, if you insist that style is more important, let me tell you that I use one and only one style consistently. You may not like it, but it is everywhere the same. Since the code works correctly, it is stupid to fix what isn't broken.Since you hardly need to add any database related features to the drivers, your claim that it would take several people a long time to port all the drivers is absurd.Things would be easier, if Metabase wasn't so ugly coded!
Performance? What performance improvements were done after MDB was started that were not part of Metabase? Changing code readability according to your rules is just making cosmetic changes because it absolutely adds no functionality.As a matter of fact, I always told you to leave the cosmetic fixes that PEAR people insist that is necessary to a later phase. That was used as an excuse by Metabase detractors to stall the merge.You consider performance, code readability, easy use of your code as cosmetics? Now I understand why noones likes this poor guy.
Wrong! Many bugs were introduced because you decided to rewrite code that was working but you interpreted it wrong and rewrote broken. Making mistakes is normal, but since rewriting added no functionality that was a mistake that I well warned against. Did you listen? Of course not.Since people are now willing to accept Smarty without requiring any pearification, there is even no longer that argument of stalling Metabase x PEAR merger because after all I proved to be right from the beginning that the pearification process would be needlessly lengthy and error prone because whoever does it is always at risk of introducing bugs where none existed.Most Bugs we introduced where caused by your ugly code, which just was not very well readable.
The truth is that you added no functionality to most of the code that was rewritten to conform to pear rules. I warned against that because it would be error prone and you added bugs. I am not a wizard with a crystal ball but I guessed that would happen because my real world experience tells me that it is what usually happens.I come here and bother to share my real world experience but still I have to put up with unexperienced people claiming that the cosmetic fixes, which is mostly what pearification means, are necessary, when all we see is that those that claim pearification as necessary will not do a damn thing to help.pearification is not the point. Making MDB a set of classes which are easy to use is the goal. Oh well, now I notice, we are making progress on this path by using pear standards. They help. Well ... maybe I just have no real world experience.
You forgot that it was me that wrote 12,000 lines of code of 6 drivers and integrated 2 more drivers that were contributed. Redoing that to conform to PEAR style rules is silly and does not contribute to generate any income to support my family.Porting just to MySQL or PostgreSQL will not assure that the portability assumptions were right, despite Metabase original drivers were proved to be as portable as they could be. The problem is that Lukas keep making changes before other drivers are ported and such changes eventually break portability.Ok. Please step forward and help to write some drivers. You are the
guy with real world experience. At the moment the only thing, which slows development of MDB down is the fast, that we need to read and write such long mails for nothing.You don't have to.
You ignore the history. Not only I wrote Metabase but it was me that proposed the merge between Metabase with PEAR-DB and suggested that Lukas lead the efforts. You may never heard of me before, but if did not do anything like that, you even would not a way to stand out in MDB development. So, get informed before making any more silly claims against me.The question is, when will people ever trust my experience and start listening? Maybe when they reach maturity and stop the childish anti-Manuel-Lemos work atitude.I never heared your name bevor I started using MDB. To me, you seem to be the childish person, who wants to heared, but no one wants hear.
Christian Dickmann Yet Another childish anti-Manuel-Lemos guy?Your message speaks for yourself. -- Regards, Manuel Lemos