[erlang-questions] Protocol Mapping

[Joe Armstrong]

On Wed, Dec 19, 2012 at 4:50 PM, 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.
>

I've been doing this for years :-)

You shouldn't have unknown commands in the protocol, and if you do
the only thing you can do is crash with a decent error message so you can
debug your program later. Having crashed some supervision layer should try
and repair the damage.

But if you do only have atoms and integers and you stick to your
conventions it will be fine. You should also add a final exit clause

...
?transcode(done, 102);
transcode(Last) -> exit({transcode,bug,Last}).

The important thing is to crash if you get an unknown code.

Produce two errors - a polite error for the user, and a long and
informative error in the log for the developer

Cheers

/Joe


>
>
>
> 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
>>
>>
>
> _______________________________________________
> 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/72c3ac48/attachment.htm>