[erlang-questions] Protocol Mapping

[Daniel Goertzen]

That does weaken things, but you can fix it with a wrapper:

encode(Val) when is_atom(Val) -> transcode(Val).
decode(Val) when is_integer(Val) -> transcode(Val).



Or add a direction parameter to transcode():

-define(TRANSCODE(Atom,Int), transcode(decode,Atom) -> Int;
transcode(encode,Int) -> Atom).

?TRANSCODE(hello, 100);


yields...

transcode(encode, hello) ->
    100;
transcode(decode, 100) ->
    hello;



Dan.

On Wed, Dec 19, 2012 at 9:50 AM, Max Lapshin <max.lapshin@REDACTED> wrote:

> it is a very bad practice to have one function for  atom() -> int() and
> int() -> atom() that will detect whether it is encoding or decoding.
>
> You will meet some unknown commands in protocol and decide to bypass them
> as an integer. Everything will break.
>
>
>
> On Wed, Dec 19, 2012 at 7:47 PM, Daniel Goertzen <
> daniel.goertzen@REDACTED> wrote:
>
>> This worked for me:
>>
>> -define(TRANSCODE(Atom,Int), transcode(Atom) -> Int; transcode(Int) ->
>> Atom).
>>
>> ?TRANSCODE(hello, 100);
>> ?TRANSCODE(help, 101);
>> ?TRANSCODE(done, 102).
>>
>>
>>
>> Inspection of the expanded output with compile:file(File, ['P']).
>> shows...
>>
>> transcode(hello) ->
>>     100;
>> transcode(100) ->
>>     hello;
>> transcode(help) ->
>>     101;
>> transcode(101) ->
>>     help;
>> transcode(done) ->
>>     102;
>> transcode(102) ->
>>     done.
>>
>>
>> Dan.
>>
>> On Wed, Dec 19, 2012 at 6:50 AM, Steve Davis <
>> steven.charles.davis@REDACTED> wrote:
>>
>>> Hi,
>>>
>>> I'm frequently facing situations with binary protocol
>>> translations/transforms where I need to map binary codes to e.g. atoms and
>>> back.
>>>
>>> This is of course "easy" in Erlang, but suffers some
>>> inconveniences. I've attached a code snippet distilled down to the simplest
>>> case to explain my issue.
>>>
>>> I'm sure the first codec pattern below is familiar, and for sure is
>>> efficient.
>>> However, there are multiple places where updating is required to add new
>>> message types.
>>>
>>> The second pattern is much less usual, but handy as one line achieves
>>> the addition of a new message type.
>>> It helps particularly when there is more than one pairing involved (e.g.
>>> {atom, code, status_message}).
>>>
>>> For sure this cannot be something nobody has seen/thought about. I'm
>>> wondering if anyone has comment on this, and maybe suggestions for
>>> approaches that I haven't thought of.
>>>
>>> /s
>>> -------
>>> -module(mapping).
>>>
>>> -compile(export_all).
>>>
>>> %% traditional
>>>
>>> -define(HELLO, 100).
>>> -define(HELP, 101).
>>> -define(DONE, 102).
>>>
>>> encode(hello) -> ?HELLO;
>>> encode(help) -> ?HELP;
>>> encode(done) -> ?DONE.
>>>
>>> decode(?HELLO) -> hello;
>>> decode(?HELP) -> help;
>>> decode(?DONE) -> done.
>>>
>>> %% alternative
>>>
>>> -define(MAP, [
>>> {hello, 100},
>>> {help, 101},
>>> {done, 102}
>>> ]).
>>>
>>> encode0(X) ->
>>> {X, Y} = lists:keyfind(X, 1, ?MAP),
>>> Y.
>>>
>>> decode0(X) ->
>>> {Y, X} = lists:keyfind(X, 2, ?MAP),
>>> Y.
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121219/80c1b7fd/attachment.htm>