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

On Sunday, September 15, 2002, at 01:27 PM, Eric wrote:

On Sun, 15 Sep 2002, Lux wrote:

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).

I'm sure we've all developed our own application libraries that we could use well before PEAR's inception. I've been working hard to convert all of my existing code to the "standard." This may or may not be feasible for everyone, but I would rather spend my time developing my software than updating and maintaining a database abstraction class. Obviously, this is a personal preference that is most likely decided by the amount of work it takes to update code with a different API. :)

The main thing preventing a change of coding style for a lot of projects is the fact that they are used by more than just the original developer. This means API changes that might add PEAR conformance would break the code of everyone using that library. Metabase is a good example because it is very popular, and sure the internal code might not be what you call pretty, but the API is what it is and the decision to change that API would mean not only Manuel has to change his existing code to work with the changes, but everyone who uses Metabase would have to do the same. There's no way around this in a lot of cases, including Manuel's and mine. Forcing internal coding standards for the purpose of code maintainability while encouraging a certain naming standard for future packages is one thing, but forcing API changes is what prevents good coders from helping make PEAR the reality it could be. PEAR came too late in the game to expect people to start changing their APIs to contribute. As a result, PEAR loses out and the whole PHP community loses out. I know maintaining my own db abstraction sucks, but it's come as far as PEAR's has, and I have had hundreds of downloads this month alone which means I'm stuck with the one I've got, and I'm stuck maintaining the one I've got. I've also got megs and megs of code using my API, and it's much easier for me to fix the occasional bug and add the occasional feature than to update all of that for the sake of PEAR. Maintaining a db abstraction is a very small part of maintaining an application framework.

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

I had some minor changes in my coding style to conform to pear. I spent an entire weekend fixing just one class -- and it's still not fully done.

PEAR compliance is not even on my 'to do' list because of this. I write software to make a living, and things like this eat time that could be spent on actual improvements to my software which translates into me eating and living month to month. This sounds like the reason Manuel didn't help as much as some would have liked on things like MDB. Metabase works. Spending the months it is taking to turn it into MDB would be taking time away from work that could be used to put food on his table (and his family's). That being said, it will be nice to see a unified database abstraction layer in PHP. While choice is great for us, it doesn't do much for our credibility, and credibility is what will bring PHP into the more cautious businesses that still regard it as some renegade fad or unscalable toy. And when PHP hits these places, it only means more chance to make money and keep eating for us, which could mean more time on things like PEAR. (Notice the "chicken and the egg" dilemma here :)) Also, if I knew I could keep my API, and just had to clean up my internal code so that it meets certain legibility criteria (spaces not tabs, indents and braces like so, etc.), I would maybe have considered PEARifying my classes. But since I can't make both my users and the PEAR dudes happy, I have to choose my users. I gotta represent, you know? (Sorry, too much gangsta rap lately) Anyway, that's my two cents and I'm out. No sense starting another argument about PEAR coding standards (maybe I already did. if so, sorry!). We've had plenty of those before. ;) Lux

I think it is incredibly important that the coding style be mandated. Otherwise, you end up with people creating all sorts of wacky ugly code. At that point, each "module" is separated. Modules created by author xxx look and act incredibly different than modules created by author yyy. The recent talk about a standard set of methods for classes is also a good idea. Building a string representation of a class suitable for display should be the same across the board, regardless of the module. It will make the entire project much easier to use. Defining and enforcing these standards make the entire project more useful as a whole. If we didn't do this as a community, we would merely have and easy way to download PHP libraries (ie. CPAN). Why not build an application framework instead of a code library? -eric

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