perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kennedy <>
Subject Re: independent version tracking per-Apache-module
Date Wed, 23 Mar 2005 14:14:59 GMT
I should note that my experience with two-dimensional class structures 
has been less than ideal, and would tend to suggest what you want would 
be quite difficult.

If one dimension is the function in each of the set of all 
ApacheX::Modules, and the second is the versioning, there are all sorts 
of issues, such as the following...

package Apache::Foo;


sub add_child {
	my $self = shift;

	push @{$self->{children}}, Apache::Bar->new;

while you can sub-class Foo quite comfortably, when you ->add_child it 
still wants a Bar, which means doing things like...

	ref($self) =~ /^Apache::(.+)$/ or die;
	my $child_class = $1;
	push @{$self->{children}}, $child_class->new;

My CVS Monitor project is encountering such a situation as we speak in 
doing a two-dimensional set of driver classes. Each driver needs to 
implement 6 classes...

So far, my solution has been to add a ->Driver method to each class 
pointing back to the base driver class, and then a ->File, ->Version, 
etc method pointing to the appropriate member class.

The equivalent of the above becomes

    push @{$self->{children}, $self->Driver->Bar->new;

For me, the extra cost is worth it, since it occurs as part of a process 
with runs once a day (with the results Storable'd).

mp2 does not have that luxury.

I'd like to see a proof-of-concept implementation of the class structure 
you are suggesting.

Adam K

Dominique Quatravaux wrote:
> 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/ 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
> Version: GnuPG v1.2.5 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird -
> SPioq6EN19pnwz2JyuqcdQg=
> =ZB4K
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message