<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 4, 2014 at 2:09 PM, Rudolph van Graan <span dir="ltr"><<a href="mailto:rvg.mailing@me.com" target="_blank">rvg.mailing@me.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Any suggestions?</blockquote></div><div class="gmail_extra"><br></div>You are modelling your data such that illegal data is representable. This is usually a mistake based on the lack of proper sum-types in the language of choice. The sum-types can be emulated in Erlang by use of tuples. Say we have</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">#{ a => x, b => 8 } and #{ a => y, c => 9 }. Here, the 'a' key steers whether or not the 'b' key and the 'c' key are valid. But if you use</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">-spec t() :: {x, integer()} | {y, integer()}.</div><div class="gmail_extra"><br></div><div class="gmail_extra">as your representation, then you can match directly on the structure:</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">case Struct of</div><div class="gmail_extra">  {x, B} -> ...;</div><div class="gmail_extra">  {y, C} -> ...</div><div class="gmail_extra">end,</div><div class="gmail_extra">

<br></div><div class="gmail_extra">and there is no way we can represent the data #{ a => x, c => 9 } for instance.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The resolution is to pick a better representation format of your data. And to aggressively convert badly formed data at the system border.</div>

<div class="gmail_extra"><br clear="all"><div><br></div>-- <br>J.
</div></div>