Michael G Schwern wrote:
Just because there is a new version on CPAN doesn't mean everyone updates in
lock step or should not have to *especially* for a toolchain module which
should strive to avoid interdependencies. It should be possible to update MB
without updating version.pm and vice versa. MB should not require the latest
version of anything (it shouldn't require anything).
M::B has a hard dependency on version objects; it makes the M::B code much more
robust and consistent. Consequently, if version.pm isn't already installed,
M::B will provide its own copy instead, which is, in fact, the exact same code
that the CPAN version.pm release contains. There are three states:

1) No version.pm installed - M::B will unpack and use the compatibility code it

2) Older version.pm installed - M::B will unpack and use the compatibility code
it carries.

3) Newer version.pm installed - M::B will use the installed version.pm code (XS
or pure Perl, it doesn't matter).

I keep M::B in sync with version.pm's own CPAN release now, only because there
have still been some behavioral changes with version objects. Once v5.10.0 is
released, and version.pm goes gold at 1.0, it is very likely that M::B wouldn't
ever have to be updated, since the existing code does everything that M::B needs
it to do. Either M::B or version can be upgraded independently and everything
will still continue to work.
This line of thinking mortgages the future.
Please remember that the CPAN release of version.pm is just a compatibility
module for the Perl core version object code, which is literally compiled into
the Perl binary. Once v5.10.0 is released, that API is frozen. Any future CPAN
release has to be compatible with the core code. I have a way to override what
is in the core (which is what Andreas is going to use), but it happens at
runtime only.
But you're not testing the methods and behaviors, you're testing the guts.
At some point in any class, some piece of code is allowed to peer into the guts.
The constructor gets to know about the internals of the object, because it is,
you know, *constructing* the object. The public API can use private API calls,
or even access the object internals directly, because the actual implementation
is dependent on the actual internal representation.

Among other things, calling Perl object methods from XS code is slow and messy.
It would greatly obfuscate the XS code to have all of the public API code
relying on object methods that are not part of the public API to compose or
decompose the object.
Either test the behaviors directly via the public API, allowing subclassers to
get creative, or just trust that other people know what they're doing and drop
the check entirely.
After thinking about it, I realize that this really isn't a matter of validating
subclasses at all, or even public vs private API; it is a matter of abstracting
a common bit of code out. I had to do those checks in other parts of code
anyways, which is why I made a private function to do it in one place.


John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Blvd
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 13 of 14 | next ›
Discussion Overview
groupmodule-build @
postedJul 10, '07 at 5:01a
activeJul 17, '07 at 1:22a



site design / logo © 2019 Grokbase