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

Culley Harrelson wrote:

That is convenient but it wouldn't take the sting out of being stuck on version 3. If there was a fork for version 4 HTML_Quickform3 would probably grow a thick layer of dust and mold as all bug fixes, patches and upgrades went into version 4. Theoretically maintenance would still happen on 3 but the harsh reality is that most maintainers don't want to put a lot of energy into back patching. Breaking BC is painful for library users however you package it.

This is correct. You'll notice that breaking BC has always been painful for users. However, until the BC-breaking regulation, it was not nearly as painful for developers. The BC-breaking regulation creates a serious incentive to design an application with a good public API the first time through things. BC breaks will become much less common as PEAR matures. If a library is well-designed, BC breaks need not be so painful. As you know, the BC breaks in HTML_QuickForm are really minor. You could easily write an extended class that wraps the new method parameter orders. Fixing 212 forms suddenly becomes very easy: 1) s/require_once 'HTML/QuickForm.php'/require_once 'MyQuickForm.php' 2) s/new HTML_QuickForm/new MyQuickForm voila. 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... The important deal here is if your application *is* static, then you can use a "static" version of a package (install it permanently in a private location and never upgrade), and if your application is dynamic, you have the option of upgrading as well. This is the true strength of pear - it supports both development paradigms quite effectively. Greg