Re: can I depend on stable PEAR classes to not change?

Culley Harrelson wrote:

On Tue, 24 Aug 2004 17:42:10 -0400, Greg Beaver <cellog@php.net> wrote:

Culley Harrelson wrote: 1) s/require_once 'HTML/QuickForm.php'/require_once 'MyQuickForm.php' 2) s/new HTML_QuickForm/new MyQuickForm voila.

not voila. QuickForm3 introduced renderers. If you were using Quickform2 methods setElementTemplate() and addData() to significantly customize your output then a couple of substitution commands isn't going to bail you out.

There is no QuickForm3 or QuickForm2, there is QuickForm version 3 and QuickForm version 2. HUGE difference in terms of what you can do with it.

If you plan to use PEAR, you must plan to either use moldy old packages, or adapt to the future. PHP is the same way. You could still use moldy php3 applications, or you could redesign to take advantage of php5. It all takes work, perhaps you should consider taking up something less dynamic than programming, like accounting ;). Of course, tax law is constantly changing and so I guess even that isn't so static...

This sounds like a weak excuse for library authors to screw with the API. I am self employed, writing applications in php that pay my mortgage and feed my kids. My livelihood depends on the stability of the libraries I use. I have a 1500 line todo list and *no* time to go back and rewrite code because a library has changed it's api. I want to rewrite code when my business changes and that is it. When I have to rewrite code because the library API changes I see it as an indication that I chose the wrong library to use in the first place. Whoops!

Perhaps, but the fact that you are ignoring the part of my message where I describe the incredible amount of energy, collective and personally, that has gone into fixing the problems you've experienced for all future packages leads me to believe that there is nothing I can say or do to make you happy. How much time have you saved versus time you have lost using PEAR packages? If you could have coded a custom solution in less time than it took to implement (and work around problems) in PEAR packages, then you are probably right, you chose the wrong package. This specific case is again from the past, which makes the paragraph I quote nothing more than FUD. You could always rely on Microsoft products. They are happy to take away all of your money to give you products that are twice as buggy and closed-source so that any bugs you find are your own tough luck. Whoops. Sorry, Greg