<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Record selectors</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>> well, what about packages? This is basically what they were </FONT>
<BR><FONT SIZE=2>> designed for!</FONT>
</P>
<P><FONT SIZE=2>Well, if I wanted to play the great directory hunt then I'd use Java!</FONT>
</P>
<P><FONT SIZE=2>Seriously there is a great deal of legacy code (perhaps every system written since the invention of gen_server) which relies on this behaviour so I don't think removing it is an option.</FONT></P>
<P><FONT SIZE=2>I also just thought for a few milliseconds more about my suggestion of using xref, and realised that all knowledge of records is lost pretty early in compilation. This information certainly does not make it into the abstract code stored in beam chunks used by xref and not even through the "All source code transformations" stage - compiler option 'E'.</FONT></P>
<P><FONT SIZE=2>So, it would seem that even to make a simple analysis tool would require the compiler to hold onto the knowledge of record definitions a few more steps into the process (before finally turning accesses into erlang:element/2 calls). Any comments from Compiler writers??</FONT></P>
<P><FONT SIZE=2>Sean</FONT>
</P>
<BR>
<BR>
<P><B><FONT SIZE=2>NOTICE AND DISCLAIMER:</FONT></B>
<BR><B><FONT SIZE=2>This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information.</FONT></B></P>
</BODY>
</HTML>