<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace">Hello Nathan,</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">> 
I'm glad it worked so well.  I was dubious since you are parsing English. <br></div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Thank you very much. Yes, spoken languages carry so many more edge cases than a programming/syntactic language. That's partly why I applauded records and their maintainability. The main reason I kept refactoring my code so much was to adapt to an edge case that I had forgotten/not thought of.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">> 
In general, I like to keep the parsing logic in the class of the 
resulting object.  This way each class deals with the specifics for that
 class.  The downside is that some logic may be duplicated.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Agreed. And yes, some duplication was involved, but frankly, it's a small cost in comparison to the simplified flow. Now if only I could turn this into some mapping that I could fetch from the sealed type. Someone else on this thread suggested using annotations to serve as my bridge between worlds. Let's see if that can serve as my mapping.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Thank you for your help!</div><div class="gmail_default" style="font-family:monospace">David Alayachew<br>

</div></div></div>