[erlang-questions] Replacing a module with another module

Joseph Wayne Norton norton@REDACTED
Thu Apr 21 07:39:54 CEST 2011


Oh yes, sorry!  This patch is in my own repository.

https://github.com/norton/meck/commit/8ea00f438695838f4cee4e2b13928abcac17f9b3

thanks,

On Thu, 21 Apr 2011 14:36:49 +0900, Dmitry Demeshchuk  
<demeshchuk@REDACTED> wrote:

> Just to mention, looks like at the original meck the function
> rename_module still remains internal.
> Nevertheless, it's very simple, so no big deal.
>
> On Thu, Apr 21, 2011 at 9:29 AM, Dmitry Demeshchuk  
> <demeshchuk@REDACTED> wrote:
>> Hi, Joseph.
>>
>> Thanks, that's exactly what I was looking for!
>>
>> On Thu, Apr 21, 2011 at 9:26 AM, Joseph Wayne Norton
>> <norton@REDACTED> wrote:
>>>
>>> Dmitry -
>>>
>>> Hi.  The meck module recently exported some of it's internal utility
>>> functions.
>>>
>>> The recipe below works quite well for my purposes.
>>>
>>> thanks,
>>>
>>>
>>>
>>>
>>> -module(mocking_module).
>>>
>>> -define(MOCK_MOD, module_to_be_mocked).
>>>
>>>  :
>>>  :
>>>  :
>>>
>>> install_module() ->
>>>    ok = uinstall_module(),
>>>    Forms = meck:abstract_code(meck:beam_file(?MODULE)),
>>>    ok = meck:compile_forms(meck:rename_module(Forms, ?MOCK_MOD),
>>> meck:compile_options(?MODULE)),
>>>    ok.
>>>
>>> uninstall_module() ->
>>>    code:purge(?MOCK_MOD),
>>>    code:delete(?MOCK_MOD),
>>>    ok.
>>>
>>>
>>> On Thu, 21 Apr 2011 14:15:02 +0900, Dmitry Demeshchuk  
>>> <demeshchuk@REDACTED>
>>> wrote:
>>>
>>>> Actually, this task is very similar to how meck, effigy and similar  
>>>> stuff
>>>> work.
>>>>
>>>> So, there's a module named foo that is working. And there's a module
>>>> foo_mock, we want to mock a lot of stuff from the module foo here. Of
>>>> course, we could just use 'start_mocking' function where we declare
>>>> standard meck rules, like
>>>>
>>>> meck:new(foo),
>>>> meck:expect(foo, bar, 0, fun() -> stuff end).
>>>> meck:expect(foo, bar2, 0, fun() -> stuff2 end).
>>>> ...
>>>>
>>>> But this is obviously ugly.
>>>>
>>>> So, the more general way of solving this is to get abstract code of
>>>> the module foo using beam_lib, map through it, replacing the module
>>>> atoms, and compiling it back again.
>>>>
>>>> My questions are:
>>>> 1. Is there an easier way? (Besides loading a module with the same
>>>> name from another path, the circumstances don't allow me that)
>>>> 2. Hasn't anyone already done that? Maybe I'm trying to re-invent
>>>> something obvious here.
>>>>
>>>
>>>
>>> --
>>> norton@REDACTED
>>>
>>
>>
>>
>> --
>> Best regards,
>> Dmitry Demeshchuk
>>
>
>
>


-- 
norton@REDACTED



More information about the erlang-questions mailing list