Re: Re: [metabase-dev] MDB news (http://pear.php.net/package-info.php?package=MDB)

On Saturday, September 14, 2002, at 06:50 PM, Ondrej Jombik wrote:

                                        Maxim, 00:48:56
                                        14. september 2002 (sobota)

Greetings.

It is very likely that I never will use PEAR code. It is nothing personal to anybody. I just disagree with the design and the silly style requirements.

Till this time I aggree with almost everything you wrote, but now I'm little bit confused with your opinions. You say, that you will never use any PEAR code, because of its design and silly style requirements. But wasn't that you, who transplanting opinion, that coding standarts are not relevant and important?

I believe what Manuel was saying is that he already has a sufficiently mature self-produced equivalent to PEAR, which probably arose due to the lack of a standard library in PHP, and that as a result of this he probably won't need any of PEAR because it duplicates what he already has and is already familiar with. It was not a stab at PEAR. I'm in the same boat myself. My own "application framework" is now 100+ classes in size. I won't be giving this up for PEAR when 4.3 comes to town, and I won't be giving it up for PEAR when 6.0 come to town. My API is entrenched in existing applications. Plus, it's been under development for longer than PEAR has even, and it's very good in my opinion. Plus I document the hell out of it, but it's not in PHPDoc because I wrote my own DocReader (as I call it) before PHPDoc was even around. No biggie. I've also already had DB abstraction before PEAR was even around (sure Metabase kicks it's ass in functionality, but whatever ;)), and I've been using a custom "CGI" class (inspired by CGI.pm, I used to be a Perl guy) for a good 2 years before PHP finally decided it was bad to use register_globals. But I still appreciate what PEAR and PHP Classes are trying to do. I've gotten more use out of PHP Classes than PEAR so far, but I follow PEAR with great interest (it appears Manuel does also). The coding standards don't match my own, sure, and since I have users already relying on my API I can't go changing mine to match PEAR's (which is what prevents me from contributing), but a standard library does need some level of consistency. I can dig that. But I think the real reason people have a problem with the coding standards in PEAR is that PEAR came in pretty late in the game, and people already have code ready to contribute, but a lot of that code falls under the "can't break backward compatibility"/"doesn't comply with the coding standards" paradigm, and that makes people upset because they have this great stuff they can't contribute to what will be PHP's shiny new standard library. Does this shit make any sense? :) Lux

One time code is good and works well, it is not important that it is ugly coded. I think so, although I do welcome PEAR coding standarts for further easy maintaining and contributing. I suppose, that we have the same opinion at least on the first sentence. But now you say, that you will not use PEAR code because of its silly style, although it will be good and well-coded. =Nepto= ____________________________________________________________________________

Ondrej 'Nepto' Jombik, http://www.nepto.sk/              nepto@atomicpile.sk

--PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

-- John Luxford Simian Systems _______________________ phone : 204.946.5955 email : lux@simian.ca web : www.simian.ca _______________________ web content management application development consulting and training