Structs (was RE: Record selectors)

[Sean Hinde]

I'm not sure if all of this has been suggested somewhere.. and I don't have
time to re-read the whole thread, but I've been thinking of how to help the
situation where people would define a struct locally in two modules (with
perhaps an erroneous difference in definition), and send a message
containing that struct:

-module(a).
-struct(msg, {header, content}).
loop() ->
	receive
		~msg{header = H, content = C}
	end.

-module(b).
-struct(msg, {header, conten}).

send() ->
	a ! ~msg{header = <<1,2,3>>, conten = <<4,5,6>>}.

My proposal is that structs should be made strictly local or external - just
like function calls. So:

* Sending a locally defined struct to another module with the "same" struct
also locally defined would *never* match (I see some implementation where
the module name is encoded into the opaque struct type).

* In order to match an externally defined struct it would need to be
imported or fully qualified:

-module(a).
-export_struct([msg/2]).
-struct(msg, {header, content}).
loop() ->
	receive
		~msg{header = H, content = C}
	end.

-module(b).
-import_struct(a, [msg/2]).
send() ->
	a ! ~msg{header = <<1,2,3>>, content = <<4,5,6>>},
	a ! ~a:msg{header = <<1,2,3>>, content = <<4,5,7>>}.

Overlapping named locally defined structs would behave in the same way as a
name clash for modules (dunno which way round, never used import!) but
generate a compiler warning.

The problem of code replacement is then no worse than for modules.

This would give tools like xref all the help they needed to know which
struct was being referred to at any time.

And I would dump anonymous structs (sorry Joe).

I think it would then be OK to reduce runtime checking to the minimum needed
to ensure emulator safety (bounds checking).

Thoughts? Particularly about the locally defined structs never matching
between modules (as I do recall seeing everything else before..

Aternatively we could move wholesale to UBF :-)

Sean



NOTICE AND DISCLAIMER:
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20030120/68a095c0/attachment.htm>