Why do they need to be atoms?<div><br></div><div>We have a very similar case, where we take HTTP headers from calls to our own servers and turn them into proplists, with atoms for the header kinds ("content-type," "cache-control" etc).</div>
<div>However, we'd probably be just as well off, if not better, to use binaries as the keys -- we get those straight out of the HTTP request anyway. Then we don't have the problem of growing atom store, and/or having to pre-declare all possible headers we might care about.</div>
<div><br></div><div>Sincerely,</div><div><br></div><div>jw</div><div><br clear="all"><br>--<br>Americans might object: there is no way we would sacrifice our living standards for the benefit of people in the rest of the world. Nevertheless, whether we get there willingly or not, we shall soon have lower consumption rates, because our present rates are unsustainable. <br>
<br>
<br><br><div class="gmail_quote">On Thu, Oct 13, 2011 at 6:24 AM, Eric Newhuis (personal) <span dir="ltr"><<a href="mailto:enewhuis@gmail.com">enewhuis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div>The problem is with list_to_existing_atom/1.  Really it is a great idea.  But...</div><div><br></div><div>1.  I have raw query strings coming in from the cruel outside world.</div><div>
2.  I convert some bits of those into atoms by way of list_to_existing_atom so that someone cannot kill me with DOS attack by bloating my atom table.</div><div>3.  With me so far?  Good.</div><div>4.  My server, an OTP app, has a .app file that lists several other apps.</div>
<div>5.  list_to_existing_atom fails on atoms defined in those several other apps.</div><div><br></div><div>Suggestion:  The documentation should specify what "exists" really means.</div><div><br></div><div>Question:  What should I do to force the atoms from my dependent apps to be loaded?  I've been manually calling Module:module_info/0 just in time but, alas, this is starting to fail due to other module dependencies that are unknown at my call sites.</div>
<div><br></div><div>For reference, here is the existing Erlang doc from the .org site:</div><div><br></div><div><a href="http://www.erlang.org/doc/man/erlang.html#list_to_existing_atom-1" target="_blank">http://www.erlang.org/doc/man/erlang.html#list_to_existing_atom-1</a></div>
<div><p><a name="132fd748d68aa648_list_to_existing_atom-1"><span>list_to_existing_atom(String) -> atom()</span></a><br></p>
<div><p>Types:</p>
        <div>
<span>String = string()</span><br>
</div>
      </div>
<div><div>
        <br></div><p>Returns the atom whose text representation is <span>String</span>,
          but only if there already exists such atom.</p><p>Failure: <span>badarg</span> if there does not already exist an atom
          whose text representation is <span>String</span>.</p></div></div></div><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>