<!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>Hi,</FONT>
</P>
<P><FONT SIZE=2>All attempts to make records a bit safer are welcome - I have a couple of comments on your suggestion:</FONT>
</P>
<P><FONT SIZE=2>> - one problem today is that records are effectively </FONT>
<BR><FONT SIZE=2>> module local (since they only exist as such at compile-time). </FONT>
</P>
<P><FONT SIZE=2>I have grown very used to using the same record name (locally defined) in lots of different modules - not least in the gen_server where just about every one ever written surely has a #st() or #state{} record.</FONT></P>
<P><FONT SIZE=2>I think that such a scheme as you suggest would need to kep the ability to have totally module private record definitions as well as your global definitions.</FONT></P>
<P><FONT SIZE=2>One further thought - we use the xref tool as part of our build process. This is invaluable in discovering calls to undefined modules in corner cases (try calling error_logger:format("Aargh") ). If xref could be extended to find inconsistencies in use of records across a set of modules maybe that would be sufficient?</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>