[erlang-questions] Finding inconsistencies in record definitions and pretty printing records
Wed Oct 15 16:39:18 CEST 2008
Agree. All this thing sounds to me like some kind of type check but neither
in compile time neither runtime, but in load time. It's like fairy tale,
neither naked, neither dressed. With global name space it easy become to
On Wed, Oct 15, 2008 at 4:24 PM, Ulf Wiger (TN/EAB)
> Joe Armstrong skrev:
> > On Wed, Oct 15, 2008 at 2:38 PM, Ulf Wiger <ulf@REDACTED> wrote:
> >> 2008/10/15 Thomas Lindgren <thomasl_erlang@REDACTED>:
> >>> Does it handle multiple definitions of the same record name?
> >>> (#state, to take the canonical example)
> > Yes - it reports an error if two record declarations are not
> > identical
> >> This is what prompted me to introduce an -export_records()
> >> directive in my exprecs contrib.
> >> If I have records that I only use inside one module, I don't really
> >> care if similar, but different, records are used elsewhere.
> > And you promise not to send a message containing a private record,
> > anywhere - and you promise that some other process will not send you
> > a message with this record and you promise not to store a record in a
> > data base - ....
> Yes, just like I promise not to mess with data structures documented
> as "opaque", or mess with contents of ets tables, just because
> they're created as 'public', or send bogus messages to other
> processes just because I can, or mess with other programs' mnesia
> data, for that matter.
> I also restrain myself from calling
> rpc:multicall(nodes(), erlang,halt,),
> even though it's perfectly possible.
> I guess the question is whether your cure is worse than the
> disease. ;-) I don't think it's very common that programs inadvertedly
> pass around their internal data structures. If you offer a way for
> people to specify some of their records as internal, they may be
> more inclined to use your solution.
> Ulf W
> erlang-questions mailing list
--Hynek (Pichi) Vychodil
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions