Re: Expect more!

Speaking of standards, would or wouldn't it be beneficial to have uniform method names? i.e., that if a method has the same function, it has the same name across all packages? that would minimize the learning curve, because there would be a kind of unified api. (e.g., the function to turn off cookie support across packages could be ->noCookies(), etc.) I'm thinking of cases where something does the same thing in a number of packages. Just a thought. I know it would probably break BC for a _lot_ of packages, and would probably be hard to get people to implement. However, I think it would make for a better learning curve. Just a thought... Klaus ----- Original Message ----- From: "Markus Wolff" <wolff@21st.de> To: "Martin Jansen" <mj@php.net> Cc: "Lukas Smith" <smith@backendmedia.com>; <stuart@myrddraal.demon.co.uk>; <pear-dev@lists.php.net> Sent: Friday, February 14, 2003 9:33 PM Subject: Re: [PEAR-DEV] Expect more! > > On Fri, 14 Feb 2003 16:42:58 +0100 > Martin Jansen <mj@php.net> wrote: > > > On Fri Feb 14, 2003 at 04:1951PM +0100, Lukas Smith wrote: > > > I am just saying that we should focus on quality over quantity. Actually > > > quantity has dangers that should not be ignored. It is hard for people > > > to figure out which package to use. More bugs will show up with less > > > developers there to fix them. Contributions will help less users, > > > because they are distributed among more packages etc. > > > > I agree. But how should we realise that? If we start saying "No, we > > don't accept your package, better merge it into XYZ." people will > > loose interest in the contribution, because of the new changes they have > > to apply to their code. > > Or, keeping the LiveUser <-> Enterprise A&A story in mind, developers > actually _are_ interested in a merge because they can see it would, in > theory, be beneficial. > > But then, there´s still the time factor - you need to inspect each > other´s code intensely, figure out what to merge and how, and then > potentially rewrite lots of application logic, test scripts and begin > debugging from scratch... basically, it would probably be easier to > start a completely new package from scratch, incorporating ideas of both > teams. > > But: How likely is it that both parties have the time to do this? IMHO, > not really likely. > > I agree that the theory is nice, though. > > Regards, > Markus > > -- > Markus Wolff <wolff@21st.de> > > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php