Polymorphic record question

[Richard A. O'Keefe]

Andrew Lentvorski <bsder@REDACTED> wrote:
	However, the extra layer of hierarchy binds me to a structural
	decision that I may not want to be held to.
	
That is the point of introducing access functions.

	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.
	
The answer is to write a tool that takes a description of a data type
and generates an encoder or decoder.  It might as well generate the
-record declarations and Erlang code as well.  The last thing you would
want to do is to write en/decoders by hand, because then it is fatally
easy for them to get out of synch.

	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.
	
You get the possibility of multiple creators.
You get the possibility of data-dependent creation, where calling a
creation function with certain values causes one kind of result to
be built and other values cause another kind of result to be built.
You get a certain amount of future-proofing.

Of course, what you *really* want is abstract patterns, which can
solve your original problem exactly the way you'd like to solve it.