[EMAIL PROTECTED] (Nick Ing-Simmons) wrote:
>Ken Williams <[EMAIL PROTECTED]> writes:
>>2) Most of the initialization code takes place when you 'use
>>ExtUtils::MakeMaker', not during the new() method. This means that
>>the initialization data is stored in global variables, rather than as
>>object member data. This in turn makes it very difficult to subclass
>>MakeMaker.
>
>Sub-classing is common - but one sub-classes not MakeMaker but MM_xxxx.
This is difficult to do in practice, because MakeMaker figures out which
MM_xxx module to load, and you can't make it load a different one unless
you change MakeMaker.
>>I would like to try reorganizing this code a bit, and I
>>hereby solicit abuse for it. ;-) If nothing else, I can make accessor
>>methods on the class data.
>>
>>3) I'm curious about why only some MakeMaker methods are overridable in
>>the MY:: package, and the rest aren't.
>
>MY:: overides ExtUtils::MM_Unix not ExtUtils::MakeMaker.
Unless I've misunderstood something, MY overrides MM, which overrides
all of ExtUtils::MM_xxx, ExtUtils::MM_Unix, and ExtUtils::MakeMaker. So
MakeMaker is a parent class of MY.
The problem is that no objects of the MY class are ever created -
instead, the overridable subroutines are manually copied from MY into
PACK001, etc., so the inheritance from MY to MakeMaker is never actually
used.
------------------- -------------------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED] The Math Forum
