in reply to Class::MethodMaker, workplace politics, and patches

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.

  • Document the whole thing very thoroughly, both in the source, and in a separate document that explains:
    1. Why the patch was required--technical reasons.
    2. Why it couldn't be applied in the normal way--polital reasons.
    3. An copy of the email sent to the author requesting the change/addition. Plus any follow-up.

    Get on with the job using the patches and give the document to your supervisor--once you have a sufficient body of work & tests to demonstrate the benefits.

    You should probably include an example of what extra work would be required or what benefits would be lost were the patch not applied.

    Examine what is said, not who speaks.
    Silence betokens consent.
    Love the truth but pardon error.
    • Comment on Re: Class::MethodMaker, workplace politics, and patches

    • Replies are listed 'Best First'.
    Re^2: Class::MethodMaker, workplace politics, and patches
    by lachoy (Parson) on Feb 11, 2005 at 22:00 UTC

      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

    		[reply]

        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.
    		[reply]
    [d/l]

    In Section Seekers of Perl Wisdom