Polymorphic record question

[Andrew Lentvorski]

Richard A. O'Keefe wrote:

> This seems like a very strange choice.
> Whoever said that a data structure could have only one level?
> When a bunch of abstract values have some properties in common
> and some properties that are NOT in common, use two levels (or
> more in some cases):

Your solution is perfectly fine.

However, the extra layer of hierarchy binds me to a structural decision 
that I may not want to be held to.

If I wish to decode those packets in a different language, the hierarchy 
inserts an extra set of decode steps which need to be compatible with 
Erlang.

I feel this very keenly having just written a decoder for BEAM files in 
Java.

> and write this as
> 
>     test() ->
> 	Q0 = queue:new(),
> 	Q1 = queue:in(mk_p2p_syn(1, foo), Q0),
> 	Q2 = queue:in(mk_p2p_fin(9, bar), Q1),

I'm not a big fan of lots of make_foo or create_foo functions.  It feels 
like get() and set() functions.  It's an extra layer of indirection and 
the consequent increase in conceptual complexity for very little gain.

I would rather keep the basic functions flat and native while making the 
unusual stuff accessible by function.  Normally, I can just access the 
sequenceNumber directly from the record because I know what the packet 
is.  When I need a generic access (the unusual case), I can call a 
function that does a pattern match.

> I'm a little surprised that the "downcasting" hack worked at all,
> and I wouldn't expect it to _keep_ working in future releases.

Yeah, I was a bit surprised that it worked, too.  Presumably the 
compiler just does a mapping from record field to tuple position number 
and doesn't bother checking the first field to make sure that the names 
match.

-a