Re: [binarycloud-dev] Re: [PEAR] Some PEAR remarks

Hello, Alex Black wrote: > > hi all, below: > > > > 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. > > Ok after reading and responding to the above... this mystifies me. Metabase > of course works everywhere. binarycloud works everywhere but I don't think > that was the point of your message, Steen.... > > could someone enlighten me so I can respond in context? :) Yes, it seems Steen had some kind of trouble setting BinaryCloud in Windows. > > > > 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. > > Disagree. If it's something a lot of people will use in an abstraction > layer, add it. Especially if the additions come with no overhead. > > Something weird like what we added to metabase (stream encryption of > database I/O) is obviously an example of something that _should_not_ be > included in the base. Yes, the overhead was mostly of compile time and maybe some extra memory. Anyway, these days with PHP Compiler Cache engine or some other form of running already compiled PHP code, probably makes that overhead irrelevant. > fetchOne is a perfect example of something that _should_ be included. You mean like MetabaseQueryField? > > > > > 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. > > Yep. > > > > > library should be fairly small, especially when it's a base class . > Take > > In theory I agree with that. But I don't agree with the above. Yes, for instance Metabase drivers base class is not so small but it provides many useful services that all drivers and applications need. That's a generalization. In driver sub classes you only redefine what needs to be different from the base class implementation. That's a specialization. When the base class is much larger than the sub classes, that is because there is a great level of reuse. Anyway, I think Vincent meant that that 800 lines for error handling is ridiculous, especially because PHP built-in error handling functions provide most of the functionality. A better design option would be to load the error handling code on demand (when error happens) because 99% of the times that it will be used it will not be needed or else your application is very unstable. Regards, Manuel Lemos