Re: Some PEAR remarks

Hello, Steen rabøl wrote: > > HI > > I hope your new release will work on w2k/IIS.... PEAR does without any > problems. You'd better tell that to Alex Black and BinaryCloud people. I'm sure he will not deny further assistance. Regards, Manuel Lemos > > Steen > > -----Original Message----- > From: Manuel Lemos [mailto:mlemos@acm.org] > Sent: 21. april 2002 13:25 > To: pear-general@lists.php.net > Subject: Re: [PEAR] Some PEAR remarks > > Hello, > > Vincent Oostindie wrote: > > > > On Sat, 20 Apr 2002 09:41:21 +0200, Stig S. Bakken wrote: > > >> As I said in another post in this thread, I think classes DB and > > >> DB_common are too feature-bloated. Methods like 'fetchOne' and > > >> 'fetchAll' simply shouldn't be there, because they do not add a > > >> new > > >> feature to the library; they only combine a couple of existing features > > >> to make using them easier to use. That kind of code shouldn't be in a > > >> library, or at least not at that level. > > > > > > Not in a library? Then where should it be? They certainly are features > > > in a library, because they provide a quick and easy way to do simple > > > queries, which makes programmers more productive. > > > > Aren't you confusing class libraries with procedural libraries? It's > > generally okay to put lots of functions in a procedural library, take the > > C string library for example. On the other hand, a class in a class > > library should be fairly small, especially when it's a base class . Take > > the C++ string class for example: it has much less features than its C > > equivalent. That's not to say the features shouldn't be in the library at > > all, but they should be somewhere else, at a different level, for example > > in a utility class with static only methods, or in a specialized > > subclass. > > > > I really don't want to sound arrogant, but I would still urge you to read > > up on how to design and implement libraries, especially class libraries. > > It is a discipline not comparable to designing applications or procedural > > libraries. It's very, very difficult to do right. > > > > All in all, I think I now have a pretty clear idea of how the PEAR > > library is designed, and I think I have said all I wanted to say about > > it. Your responses have shown that you think different about many things, > > which is of course allright. On the other hand, my viewpoints on the > > subject differ too much from yours, and my conclusion is that I will not > > be using the PEAR library myself. I hate procedural code, and to me the > > PEAR library is just that: a procedural library in the disguise of a > > class library. That's okay for many developers, so they will likely be > > very happy with your work. But I, for one, am not. > > > > Anyway, thank you all very much for your responses and opinions. I hope > > we all learned something from them. At least be sure I did. > > Have you looked into BinaryCloud? It is a different beast. It is > something very well planned ahead as opposed to the Ad-hoc contributions > of PEAR. > > You may want to take a look at it and your input is certainly well > appreciated there: > > http://binarycloud.tigris.org/ > > Regards, > Manuel Lemos > > -- > PEAR General Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php