Re: Something about PEAR policy

Björn Schotte wrote: > > Hi, > > there's a new discussion about migrating PHPLIB's > classes into PEAR. As Nathan Ruby says in his e-mail, > you PEAR folks don't want to have more than one class > for each category, e.g. two or more classes for DB > abstraction, templates and so on. > > Is that true? Hey, could we please have this discussion without the war paint on this time? ;-) In general, I am not against having several packages providing the same functionality. Countering that I am concerned about reusability, so I'm not thrilled about having five database abstraction layers either. I think it's a bad idea to cut in stone "we shall only have one class for X", but we should avoid unnecessary redundancy. If someone wants to submit his class only because he invented it, doesn't want to rewrite his code or whatever, it's bloat. If it offers new features, is more efficient, or has new and radical design, PEAR should have room for it. After all this is open source, if the rules or practice are too strict, someone will fork or start a similar project, which I would consider a failure for PEAR. What's happening to PEAR right now is that the concept is vague for most people, part because I have not spent enough time communicating it, part because it has changed on the way. I think most of the people who get some kind of ownership with PEAR perceive this (consciously or not), and the more vague the concept is, the more control the "responsible parties" feel they need to apply to avoid the whole thing from getting cancer and topping over. This is one of the reasons why the PEAR/PHPlib integration is difficult. So to get out of this mess we need to define PEAR more clearly. Maybe we could have avoided this situation if I had been more into writing philosophy instead of coding in the beginning, but today that's not my job anymore, it's ours. I got out of this one easy didn't I? :-) - Stig