Polymorphic record question
Tue Jun 20 08:17:13 CEST 2006
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
I feel this very keenly having just written a decoder for BEAM files in
> 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
More information about the erlang-questions