[erlang-questions] Re: how to patch a standard module

[Gijsbert de Haan]

James, the AST route sounds interesting, do you have that code
available somewhere?

I'll have a look at the -extends too.

Thanks for all the suggestions!

On Fri, Jan 14, 2011 at 6:01 PM, James Churchman
<jameschurchman@REDACTED> wrote:
> I have 0 experience of beam… but that sounds much more tricky than the AST method, and only has the advantage of working without a copy of the original source… just now tried -extends, but it wont take a file path, only a module atom & i don't think it allows for the file it's extending to be of the same name! so in this exact case it wont work. The AST one can be done in less than 10 lines which i can dig out if of any use. In this very specific case tho the -include() with the include directory set does the job the simplest :-)
>
>
> On 14 Jan 2011, at 16:42, Tomas Abrahamsson wrote:
>
>>>>>> I'd like to extend httpd_request.erl to handle the OPTIONS method.
>>>>>> I've managed to do this by copying httpd_request.erl into my project
>>>>>> and making sure it overrides the standard version.
>>>>>> My question: is it possible to redefine a function in a standard
>>>>>> module at runtime? Then I could define my own validate(Method, Uri,
>>>>>> Version) function (just a few lines) and keep using the standard
>>>>>> httdp_request.erl.
>>
>>> It is actually possible to to what you want. I have used a piece of
>>> code that could replace functions in existing modules by manipulating
>>> the beam code. In that project we only used it in eunit testing to stub
>>> functions in order to isolate the tested code.
>>> I'm not sure about using that method in a production system though.
>>> I don't have the code available any more so I can't provide any details
>>> about it but I think that Tomas Abrahamsson who sometimes contributes to
>>> this list could give some pointers on how to do it if he reads this.
>>
>> The stubber that Ola refers to is a bit similar to meck
>> and some other mocking libraries. It provides the
>> possibility to override all or only some functions of a
>> module, while still making the rest of the functions
>> available unchanged.
>>
>> The stubber has evolved a bit since: Klas Johansson
>> has done a fair bit of useful work on it, to say the
>> least, and I guess he might even make his work publicly
>> available eventually(?)
>>
>> It is mainly intended for (e)unit testing, though.
>>
>>
>> The way the existing modules were extended with new or
>> changed functions, was by simply renaming the beam file,
>> then provide a new beam module which either calls the
>> renamed module for all non-changed functions, or uses the
>> -extends(RenamedModule) feature (undocumented, I think).
>> The new module was compiled to a binary and loaded with
>> code:load_binary/3.
>>
>> See https://github.com/klajo/hacks/tree/master/beam
>> at Klas' repository for some code to rename a beam
>> module.
>>
>> See http://www.trapexit.org/Extend_Module for more info
>> on the -extends attribute.
>>
>> BRs
>> Tomas
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>
>
>