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.
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?).
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.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
