John Peacock wrote:
> Michael G Schwern wrote:
>> Its a verbatim copy of version.pm *now*, but things change and fall
>> out of
>> sync. What happens when version.pm 0.8 changes its guts and
>> Module::Build::Version 0.7203 tries to load and "verify" it? Kersplooy!
>
> A) the code in M::B is always going to be the same as the released
> version of version.pm; every time I update version.pm, I [shortly
> thereafter] send a patch to Module::Build to keep it in sync.
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).
> B) the internal representation has been unchanged for a long time (May
> 2005 for the hash and Feb 2002 for version-as-array-of-int), so the odds
> of any changes to the guts are very, very remote. Besides, the only
> thing that the _verify() routine is checking is whether the object is a
> hash (not going to change), contains a key called "version" (also not
> going to change), and that the value associate with that key is an array
> (not going to change either; sense a theme here?).
"I've never felt better."
–the last words of actor Douglas Fairbanks
This line of thinking mortgages the future.
>> Why is version.pm so untrusting of its own objects anyway?
>
> So that subclasses can extend the object methods, but the core methods
> must still be available and operate the same. Consider it a 'poison
> pill' defense. It also meant I could combine all of the little testing
> I did elsewhere into a single verify() routine that covered all of the
> bases.
But you're not testing the methods and behaviors, you're testing the guts.
Its like hiring a new janitor and then firing him because he uses a different
color mop than the last guy. No, what's important is that he gets the floors
clean.
By verifying that the guts of a subclass are the same as the parent's you're
restricting the possibilities of the subclasser. You're saying not only does
it have to do the same things but it has to do it in the same way. OO is all
about not caring how a thing is done, just that it gets done.
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.
