Stas Bekman <[EMAIL PROTECTED]> [02-11-2004 05:59]: > Radoslaw Zielinski wrote: [...] >> Sorry for warming up old threads, but I think it's worth to be noted: if >> the two versions are incompatible, the proper solution is a namespace >> change; in this case: APR2::* hierarchy.
>> A pity it hasn't been done with Apache::* modules, the MP_INST_APACHE2 + >> "use Apache2" hack is a real pain in the ass for the distributors (like >> Linux distributions). > As it was repeated many times here (my apologies if it's the first time > that you hear that), the reason for not embedding the version number in > the module name is because for most the user API doesn't change. So if > your module/app wants to support several generations of some other module, > whose API hasn't changed, you don't need to turn your code into a big mess. -> [1] > talking to myself: I think I should add this to the docs somewhere. I've > repeated that explanation quite a few times already. Well, this explanation was quite obvious for me, so I didn't even check the archives -- explaining why something is a PITA doesn't make it less painful. I thought that you introduced it without forseeing the future drawbacks... > Radoslaw, please grep the archives for Apache2 (I believe) to find the > relevant threads (there were quite a few of those on both lists). ...but now I did some homework, and -- suprisingly -- you knew them: <http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=99075968309515&w=2>. Then Doug came up with the hackish approach: <http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=99076168913061&w=2>. Now why is it wrong? * It relies upon changed @INC. Another thing to be remembered about. * It messes with @INC, changing the way it should be parsed. Originally, if you see $inc_file/Foo/Bar/Baz.pm, you know it's the Foo::Bar::Baz perl module. Now, it's Foo::Bar::Baz *unless* Foo equals to Apache2. The only other module I know, which does it, is Tk; it creates problems with automated dependency generators (at least), besides being a hack. * If the API wouldn't change, there would be no porting problems. Even if mp2 is mostly backward-compatible, mp1 isn't forward-compatible; is it? Now, there is no easy (automateable) way of discovering if the module works with mp1 or mp2, or for which version it was written for. * You can't use both mp1 and mp2 applications in scope of a single "PerlModule Apache::compat" (if the mp2 application is Apache::compat incompatible). * "use Apache2" isn't mandatory, so (IIRC, when I checked last time) most of the mp-dependent code doesn't do it. To patch, or not to patch? To care, or to drop&forget? * A sysadmin (or user) without Perl knowledge won't even be able to build mp2 without MP_INST_APACHE2 (for installation in DESTDIR for example), when an installation of mp1 already exists -- requires ripping Makefile.PL with sharpened $EDITOR. Yes, this Makefile.PL can be patched (MP_SHUT_UP_AND_RUN=1 for example), but it's just one of many. * Doug wrote: "xs modules will need Makefile.PL/#ifdef logic to work with both versions". Well, from my expirience, if such a logic works in any not-so-weird case and doesn't require investigation / patching, it's accidental. If you want both mp1 and mp2 on your system, you won't get away without all-the-hacks' know-how. * ...well, I don't remember more right now. All these issues boil down to one thing: you can't have mp1 and mp2 with applications for both without using hacks. You aimed for simplicity and backward compatibility, but IMHO the result was reversed in this case. How could it be avoided? Full Apache2::* namespace. Apache2::compat::Apache1 could provide Apache::*->Apache2::* aliases for compatible features and define custom Apache::* for the incompatible ones -- both types of applications could work in one interpreter. That would leave place for A2::compat::A3, and maybe for Apache::compat::Apache2. No hacks required. About the [1] mess: I don't see any. If you'd like your application to work with both, you'd write for mp1 and require the appropiate compat module to be loaded. If something's missing, we'll see it at the compilation stage, without wondering "does this method I'm using in this rarely triggered case do the same thing under mp2 with Apache::compat?". I just hope I don't repeat something already discussed. -- Radosław Zieliński <[EMAIL PROTECTED]> [ GPG key: http://radek.karnet.pl/ ]
pgpoZ0gjWpxt5.pgp
Description: PGP signature
