You ain't gonna like the suggestion but...

You are using a dynamic language, apply the patches dynamically.

That is, c&p the smallest replaceable piece of code that the patch effects, into your code. Apply the patch to the c&p and dynamically replace the sub/method at runtime.

Make that dynamic patch dependant upon the version number of the module you are patching.

Add a testcase and/or in-line test for that will detect if the pre-patched code has been fixed in a later version and if it has, disable the code and issue a warning to the logfile noting that the dynamic patch code can be removed.

Seconded. Depending on whether the next Algorithm::Dependency includes a patch from me something very similar to what you proposed will be making it into the next OpenInteract2 beta. Mine was very straightforward though (just adding a new method for some new functionality). But I don't think it's that risky since it's temporary -- once the new A::D comes out (and assuming it has my patch) I'll just bump up the version in Makefile/Build.PL and remove the workaround.

Chris
M-x auto-bs-mode

It's a useful technique. We used to send out binary patches that attached themselves to the end of the afflicted executable and patched themselves into the load table.

When the executable loaded, they checked the embedded version in the 3rd party .dll that contained the bug we were working around, and if it was broken version, patched the dynamic link tables to redirect the broken API to the substitute that we had attached to the end.

When the 3rd party library was updated, the next time the executable ran, it unhooked itself from the loadtable, and became a redundant few dozen extra bytes on the end of the executable, and the program continued, now using the (hopefully fixed) API.

Of course, you wouldn't get away with this these days because every virus scanner within a million miles would scream bloody blue murder.

Such is progress.

That said. C::MM is kind of unusual as the code that needs to be patched never actually exists on disk anywhere. It jusy comes into being in memory at compile time. Kind of tricky to C&P.

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.

Yeah,yeah. I know. I suck!

#! perl -slw
use strict;
use Data::Dumper;

package Foo;

sub new { bless {}, $_[ 0 ] }

package MyClass;
use Class::MethodMaker [

    scalar => [
        {
            -type => 'Foo', 
            -default_ctor => 'new' 
        },
        'foo',
    ],
];

sub new {
    my $class = shift;
    bless {}, $class;
}


if( @ARGV and $Class::MethodMaker::VERSION eq '2.05' ) {
    no warnings 'redefine';
    *MyClass::foo_isset = sub : method {
        package Class::MethodMaker::scalar;
        exists( $_[0]{foo} );
    }
}


package main;

my $m = MyClass->new;
print $m->foo;
$m->foo_reset;
print $m->foo_isset ? 'foo is set' : 'foo is not set';

__END__
[19:57:31.35] P:\test>430184
Foo=HASH(0x225000)
foo is set

[19:57:33.20] P:\test>430184 patchit
Foo=HASH(0x225000)
foo is not set
[download]

Thank you! This is exactly what I was looking for! :-)

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

Morning,

Sorry to be late to the party. BrowserUk, your answer is quite right; but you can make it slightly easier on yourself by simply defining foo_isset in the class before Class::MethodMaker(->import) is called. It will never overwrite an existing method. Since the example does a use, that would need to be in a BEGIN{} ahead of the use.

Mx.

I'm probably misunderstanding your post, or the POD, but doesn't this snippet from the C::MM pod indicate that when you reset something, the is_set() method return false? And isn't that the behaviour you are after?

  my $m = MyClass->new;
  my $a, $x;

  $a = $m->a;       # *undef*
  $x = $m->a_isset; # false
  $a = $m->a(1);    # 1
  $m->a(3);
  $x = $m->a_isset; # true
  $a = $m->a;       # 3
  $a = $m->a(5);     # 5;
  $m->a_reset;
  $x = $m->a_isset; # false
[download]

You missed the part about it having a default_ctor. Use of -default_ctor or -default changes the behavior of *_isset(). I'm not arguing the design decision, but I want to be able to turn off the optimization.

Here's a testcase to demonstrate what I'm talking about.

use strict;

use Test::More 'no_plan';

package Bar;

sub new { bless {} }

package Foo;

use Class::MethodMaker [
    new => 'new',
    scalar => [
        { -type => 'Bar', -default_ctor => 'new' }, 'bar',
    ],
];

package main;

my $foo = Foo->new;
isa_ok( $foo, 'Foo' );

my $bar = $foo->bar;
isa_ok( $bar, 'Bar' );

$foo->bar_reset;
ok(
    !$foo->bar_isset,
    "No get() after reset(), so why is it set()?"
);
-----------------
ok 1 - The object isa Foo
ok 2 - The object isa Bar
not ok 3 - No get() after reset(), so why is it set()?
1..3
[download]

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

I have to say, that having read a bit more about C::MM and how it works, I disagree with teh change you are making.

You question (in the tests) is:

• "If I've reset() an attribute and not yet done a get() or set(), why does it test as isset()?"

  And I would say, because it has a default.

  Therefore if you did do a get(), a value would be returned, and that value would be a real value--even if it was undef because the default was set to be undef.

  So, the envisioned use of _isset is to allow the caller to determine if they will get a legitimate value when they call get()--even if when they do call it they get undef.

  But you appear to be trying to use isset() as if it were isreset(), or possibly _isdefault().

  Which may be a desirable test to be able to perform for some reason other than testing that _reset() works--which is C::MM's test suite responsibility, not yours--but if it is, then it has different semantics to _isset and should probably be a different method.

  ---

  Examine what is said, not who speaks.

  Silence betokens consent.

  Love the truth but pardon error.

Don't be reticent to email me. As you've seen, I can be slow to reply, about which I apologize and will try to do better, but I certainly don't object to receiving the email. I rarely get to look at PerlMonks, which sucks because it's cool, so email is good.

As BrowserUk suggests, I'm very wary of what you're proposing, since it breaks the seemlessness of the -default, which is supposed to look like it's always set. I appreciate that you're asking for an override option, but the idea of adding another special case to what is already some pretty special-cased code (mostly for v1 compatibility) is scary. Perhaps you can explain what you're trying to achieve under the hood