On Wednesday, April 24, 2002, at 12:08 PM, Michael G Schwern wrote:
> On Wed, Apr 24, 2002 at 10:43:36AM +1000, Ken Williams wrote:
>>> requiring ExtUtils::MakeMaker. MM is one thing. MY is just Wrong.
>>
>> How is anybody supposed to know that? The docs give examples
>> like this:
>>
>> package MY; # so that "SUPER" works right
>> sub c_o {
>> my $inherited = shift->SUPER::c_o(@_);
>> $inherited =~ s/old text/new text/;
>> $inherited;
>> }
>>
>> So one might reasonably expect that 'MY' is a valid subclass name that
>> will get you access to the MakeMaker methods.
>
> "...you may define private subroutines in the Makefile.PL"
> ^^^^^^^^^^^^^^^^^^
>
> Docs aren't perfect, but I can't possibly see how the
> "Overriding MakeMaker
> Methods" docs gives license to do:
>
> my $MM = bless {} => 'MY';
> ...
> my($extralibs, $bsloadlibs, $ldloadlibs, $ld_run_path) =
> $MM->ext(join ' ', "-L$lpath", $libperl, @potential_libs);
>
> You don't just bless hashes directly into classes that might
> vaguely exist
> without some knowledge that you're doing naughty things.
That makes it sound so seedy. But there's no difference between
doing that and doing MY->ext(...), which doesn't sound as seedy
anymore.
The point is that the docs say that MY is a class that inherits
from ExtUtils::MakeMaker (or more precisely ExtUtils::MM_*), but
it doesn't say under what conditions, so one might reasonably
assume that it happens when you load ExtUtils::MakeMaker. This
was true (more or less) for a long time, then not true for a
while, and now it's true again.
> That code was likely written years and years ago anyway.
Yes, you'll certainly get no argument from me that it Should Be Changed.
-Ken
