<div dir="ltr">On Fri, May 10, 2013 at 4:48 AM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 05/10/2013 05:03 AM, Richard A. O'Keefe wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
     Frames are optimised (pared to the bone, in fact) for use in<br>
     record-like ways.  They are somewhere between pathetic and<br>
     hopeless as general purpose dictionaries.<br>
</blockquote>
<br></div>
I think that's the bigger issue with frames. Are they worth spending the time implementing considering they are essentially a records replacement? Records work good enough for most purposes, with the exception of upgrades, which few people do anyway.<br>
</blockquote><div><br></div><div>One of the things that's very compelling to me about frames as a record replacement is that (as I understand it), frames are fully-distinguishable as a separate data type.<br><br></div>
<div>The record abstraction is *very* leaky. Any Erlang coder who uses records has to know about - and contend with - its underlying representation as a tuple (insertion into ETS tables, for example, is something that's common and trips people up when the first atom (the record tag) is used as the key for the table).<br>
<br>Tom<br></div></div></div></div>