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 carries. 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 -- 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
