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

On Tue, 24 Aug 2004 09:40:03 -0700, Miles Keaton <mileskeaton@gmail.com> wro
te:

>
> In other words:  if I write a webapp that depends on HTML_QuickForm
> and Auth, for example - will my code be able to work as-is for years,
> while HTML_QuickForm and Auth are updated?
>

I am stuck using HTML_QuickForm 2.10 which came out early in 2003.
HTML_QuickForm 3 broke BC in fundamental ways and I can't justify the
work required to change 200 forms.

Fun, fun!

Culley Harrelson wrote:

> On Tue, 24 Aug 2004 09:40:03 -0700, Miles Keaton <mileskeaton@gmail.com> w
rote:
>
> 
>
>
> I am stuck using HTML_QuickForm 2.10 which came out early in 2003.
> HTML_QuickForm 3 broke BC in fundamental ways and I can't justify the
> work required to change 200 forms.

Again, this is all old news.  HTML_QuickForm 3 came out BEFORE the
BC-breaking regulation.  You can read all about it at:

http://pear.php.net/group/docs/20031114-bbr.php

[disclaimer: THIS IS A HYPOTHETICAL SITUATION, HTML_QUICKFORM IS NOT
CURRENTLY DOING WHAT I'M SUGGESTING]
In summary, it says that if HTML_QuickForm breaks BC again, it will be
released as a package named:

HTML_QuickForm4

This will include the class named HTML_QuickForm4, so that you could
literally use HTML_QuickForm alongside HTML_QuickForm4 in the same
script with no penalties.

Greg

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.

culley

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

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.

>
> 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!

culley

Culley Harrelson wrote:

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

>
> 
>
>
> 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

On Tue, 24 Aug 2004 19:10:36 -0400, Greg Beaver <greg@chiaraquartet.net> wrote:
>
> 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.
>

Thank you for all your hard work!  I am all for anything that can be
done to keep people from breaking BC.  Sorry if I come across as
disgruntled-- I felt like I lost a ton of my work when QuickForm 3
came out and I have never really gotten over it <grin>

> 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.
>

As time goes on, more and more I feel like writing most everything
from scratch might be the way to go...

Now, when I investigate external libraries for use in my applications
I like to see a package that hasn't had a major release in the last
6-12 months.  It seems a little counterintuitive to like static code,
but libraries should be more or less static.  Like Mail_Mime-- last
release on 2002-07-27!  Perfect-- that is what I am looking for in a
library.  DB has also done an excellent job.   Code I wrote against DB
1.2 still works today with 1.6.5.

> 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.
>

I left the Microsft camp as .NET was ramping up for *exactly* this
reason.  They take changing APIs to a whole new level-- forget
changing the API they are changing the whole platform!

culley

Culley Harrelson wrote:
 
>
>
> All code evolves not just open source code.  But evolving code
> shouldn't mean unstable code.  As a small business owner I can't
> afford to risk using a library unless I'm damn sure the maintainer
> isn't going to pull the API out from under me.  This is partially me
> being conservative but is is also good common sense.  I would expect
> corporate users of PEAR packages would be even more conservative than
> I am-- professional use requires rock solid stability.  Code libraries
> should be flexible and extensible and my code shouldn't have to change
> because the library I use changed.  A changing API is often either a
> sign of immaturity or rigidity of the underlying code-- it scares me
> and makes me question the library.
>
> I understand how things work-- sometimes an api has to change on order
> to evolve and everyone agrees that breaking BC is bad.  I only wrote
> this response because I felt I needed to defend myself a little...

As a member of the core-QA team I wanted to respond on this :)

The way PEAR now works, is that any BC break requires a new major
version, and all major versions will now become a new package, i.e.
XML_Tree will become XML_Tree2, which is as much a seperate package from
XML_Tree as Text_Highlighter is. It means that you will go to
pear.php.net/XML_Tree2 - and pear.php.net/XML_Tree will always (as much
as anything is forever :) be available, it will just become stale (but
stable :). This also means the class will be called XML_Tree2, and will
reside in XML/Tree2.php.

We (the QA team) are trying to get some automated tools together that
will do an API check at upload time, whilst it won't be as good as human
eyes it will provide a quick way to say it definately *has* changed
(i.e. a file is missing, or a function is missing)

I hope this helps to allay your fears. Of course, be sure to note the
state of the package you are installing. We allow BC breaks in any
release upto 1.0.0-stable (this includes RCs) however, we now suggest
that developement starts at a '-dev' state, and from alpha onwards BC is
discouraged, and heavily discouraged in RCs (really, only allowed to fix
bugs not discovered before RC testing) - Then BC breaks are not allowed
till a new major version is started.

- Davey

This sounds great.  Thanks Davey and Greg for your hard work!

culley

Culley Harrelson wrote:
> This sounds great.  Thanks Davey and Greg for your hard work!

Maybe here is a relaxing comment:
Nobody took anything from you! Its opensource. All past versions are on
the server. There is a public CVS server. So there is nothing stopping
you from forking the code.

regards,
Lukas