[erlang-questions] Frames proposal

[Michael Turner]

> But the title scared me. "Getting rid of records" - what should I do with
> all my code that uses records?

EEP stands for Erlang Extension Proposal, not Erlang Excision Proposal.

-michael turner

On Tue, May 1, 2012 at 11:28 PM, Max Bourinov <bourinov@REDACTED> wrote:
> Hi Richard,
>
> Thank you very much for posting your great work!
>
> But the title scared me. "Getting rid of records" - what should I do with
> all my code that uses records?
>
> I like the idea of frames a lot. It would significantly simplify my code and
> I love this idea.
>
>
> Best regards,
> Max
>
>
>
>
> On Tue, May 1, 2012 at 11:37 AM, José Valim <jose.valim@REDACTED> wrote:
>>>
>>> The implied mapping takes JSON {id: 4135, title: "title2"}
>>> to <{id ~ 4135, title ~ <<"title2">>}>.
>>>
>>> The bounded size of the Erlang atom table is a vulnerability
>>> but there is an EEP to address that; that in itself is a much
>>> more urgent issue than frames.
>>
>>
>> Exactly. In Ruby, for example, since atoms aren't garbage
>> collected, converting a JSON from an external source to a hash using atoms
>> as keys represents a security vulnerability in a web service, as someone
>> could force the "atom table" to fill in completely, so we simply don't.
>>
>> So until the atom limitation is fixed, we would be better on handling
>> JSONs as a dict or something else.
>>
>> I have read the proposal completely and I think everything is well
>> explained and defined. Even though I am not a huge fan of the syntax, I
>> think it fits Erlang well. One option that I haven't seen considered is
>> still using curly brackets as delimiters and use `{~}` to specify an empty
>> frame. This would make the common case (a frame with at least one element)
>> easier on the eyes by sacrificing a bit the not so common case (empty
>> frame). But again, we are in good hands with whatever the Erlang and OTP
>> team decide.
>>
>> _______________________________________________
>> 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
>