Perrin Harkins wrote: >>however, it's not as simple as renaming everything Apache2::*. why? it >>just doesn't scale well. for example, there are _already_ compat issues >>between mod_perl for Apache 2.1/2.2 and Apache2.0, so right away we would >>need Apache2::* for modules that use the Apache 2.0 API and Apache2.2::* >>for >>those that use the 2.2 API. then perhaps Apache3::* someday, etc... > > > I don't really see what the problem is with that. C libraries seem to do > it that way without too much trouble. What would be the harm in having > Apache2_2:: and Apache3:: and Apache27:: etc.? It's no worse than saying > "I want Apache::Foo, but from the 2.2 distribution."
well, I agree that doing it that way isn't the _worst_ thing that could happen, but I can't help but feel that perl can do better. > Is the fear that it will be too confusing to users? I think that is part of it. imagine a module like Apache::Cookie, which is able to trivially support both mp1 and mp2 in the same distribution. would mp2 users never find it because it isn't under Apache2::Cookie? would apache 2.2 users think it didn't work for them? I just can't see a naming scheme like that being anything but confusing for a CPAN namespace that is as large as ours. of course, the issue of multiple top-level namespaces also feels kinda wrong. if we were to go this route I might feel better if we stuck to an Apache::2_0::Foo type convention. but it still feels suboptimal. I was tossing around the idea of a new "api version" global. something like our $API_VERSION = 2.2; and then $class->VERSION(2.2); then CPAN (and related tools) might default to API version "1.0" for no $VERSION, but understand what we mean when the same module has "1.0", "1.1", "2.2" and "2.3" uploads on CPAN (namely that "1.1" and "2.3" become the dominant releases). sure, there are issues around this, like what to do when the last upload Foo-Bar-0.8 with API version "1.3" while the current one is Foo-Bar-0.9 with API version "1.2", and it (by itself) doesn't solve the @INC issue, but... --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
