-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Stas Bekman wrote:
| You aren't planning for the future. When a new even slightly | incompatible release will be made, by doing the currently suggested | change, you will be forced to rename all the APIs again. And | again. And again.
Point understood, but there are better ways to manage it all than to force everyone to rename all the time. How about this one:
~ * There is an ApacheX_Y::Foo module for every meaningful value of ~ X, Y and Foo (that is, for every X_Y > version where the Foo API ~ block was first introduced into the C code of Apache). ~ * If Y' > Y, ApacheX_Y'::Foo is made a trivial subclass of ~ ApacheX_Y::Foo if and only if API Foo did not change between ~ apache X_Y and X_Y', which would be most of the time. This can ~ even be automated: "perl Makefile.PL" in mod_perl X_Y' would ~ generate trivial subclasses for all versions of ::Foo between ~ X_Y excluded and X_Y' included, assuming the source tree ~ contains ApacheX_Y/Foo.pm with Y' >= Y. ~ * Equivalent modules (having such a trivial-subclass relationship ~ between them) can be interchanged without consequences in user ~ code, except for the name of the class. Conversely, attempting ~ to load ApacheX_Y::Foo under mod_perl Z (with X_Y < Z and a ~ compatibility break on API Foo between the two) throws an ~ exception (but see below).
In this way, mod_perl users are forced to rewrite / test versions on exactly those modules that they use and indeed break compatibility. Correct?
| Show me any big successful project whose product is a public API | and who embeds the API numbers in the API.
The Linux kernel does that all the time (e.g. umount() vs. umount2(), fstat() vs. fxstat()). The glibc is there to cover the gaps (just as the Web frameworks will do for mod_perl). The difference is that obsolete syscalls are maintained to the benefit of statically linked programs, but there is no reason we couldn't do that too with my scheme (replace "throws an exception" with "invokes a compatibility layer in pure Perl through horrible version test kludges"), arguably a lot of work and probably not worth it (I still contend that completely seamless upward compatibility is a job for the Web framework authors, not mod_perl).
| Even when more of the future major releases will be mostly | back-compatible with older releases and for most developers won't | otherwise require any work and maintenance pain to support more | than one generation.
I think that goal is met by my proposal above.
And a final, important note: we do not need to implement the trivial subclass pattern just yet. Shipping with Apache2:: is OK for now, the compatibility issue will only arise during the next mod_perl release cycle. Although training to such an API maintenance discipline would be a Good Thing even right now, e.g. having $r->notes($key, $val) and $r->args() work as they did in mod_perl 1 when Apache2 is not "use"d. But these are very minor issues, OK for bugfix releases IMHO.
- -- Dominique QUATRAVAUX Ing�nieur senior 01 44 42 00 08 IDEALX
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCQUC9MJAKAU3mjcsRAlOaAKCV7E0CIHtiegRVj+xkeZQN+AUFzgCcDpiA SPioq6EN19pnwz2JyuqcdQg= =ZB4K -----END PGP SIGNATURE-----
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
