<br><br>On Tuesday, May 15, 2012, Chad Albers  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Definitely.  Using Racket&#39;s hashes, I can duplicate the same functionality.<br>

<br>
But this hash mechanism bothers me, because I see a informal<br>
convention developing in Rack middleware, where the middleware starts<br>
injecting it&#39;s own state into the hash, with hacky namespaces on the<br>
keys to prevent key collisions.  I would like to avoid that.<br>
<br></blockquote><div><br></div><div><br></div><span class="Apple-style-span" style><br></span><div dir="ltr">One of the things I notice about Racket&#39;s runtime library design is the use of opaque values to avoid collisions.  For example, the way that structure properties work is to create a unique value, a structure type property descriptor, to be used as the &quot;key&quot;.</div>
<div dir="ltr"><br></div><div dir="ltr">     <a href="http://docs.racket-lang.org/reference/structprops.html">http://docs.racket-lang.org/reference/structprops.html</a>  </div><div dir="ltr"><br></div><div dir="ltr">The advantage of this versus using a plain symbol is that the association doesn&#39;t depend on the symbolic representation of the property&#39;s name, so there&#39;s no collision potential between properties that are named similarly.  Maybe you can do something similar?<span></span></div>
<div></div><br>