Re: Re: [metabase-dev] MDB news
| From: | Christian Dickmann | Date: | Thu, 05 Sep 2002 21:20:23 +0000 |
| Subject: | Re: Re: [metabase-dev] MDB news | ||
| References: | 1 2 3 4 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-8862@lists.php.net to get a copy of this message | ||
> 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.
> 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!
> 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.
> 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.
> 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.
> 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.
> 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.
> > An interbase driver is on my todo list, but only after I've ported (and
> > added to) the metabase testing script to PHPUnit (because the metabase
> > script has to go through the metabase_wrapper it involves too many
> > layers, we need testing that directly manipulates the MDB api, but it is
> > a starting point to copy).
>
> That is yet another silly needless thing. Metabase driver test
> conformance script proves that Metabase is portable as it should be. It
> doesn't matter what is underlying it, being that the original Metabase
> drivers or the ported to MDB. So, porting the tests to PHPUnit is yet
> another waste of time.
PLEASE! Let people waste their time when they want. You waste your time
writing mails ...
> > Those of us who actually use MDB need a release x.0 target which we can
> > then branch into a devel x.1 version. You can argue about what the value
> > of x should be (e.g. 0.5, 0.7, 1) but I think we something 'firm' and
> > bug tested so that;
>
> If you did not bother to make so many cosmetic changes, the chances of
> still having bugs would have been gone. It is not that I haven't warned
> about that before.
no comment.
Christian Dickmann
Yet Another childish anti-Manuel-Lemos guy?