Subj : Re: dangers of operator overloading
To   : comp.programming
From : Rob Thorpe
Date : Thu Aug 11 2005 10:13 am

Robert Maas, see http://tinyurl.com/uh3t wrote:
> > From: makc.the.gr...@gmail.com
> > So, I chose 1-byte field and simple name enumeration, which forced me
> > to implement funcs
> > func1(string s) {
> >  if(str == "blah") return 1; else
> >  if(str == "duhh") return 2; else
> >  ... 100+ lines of same c# code here...
> > and
> > func2(int i) {
> >  if(i == 1) return "blah"; else
> >  if(i == 2) return "duhh"; else
> >  ... etc...
>
> Why didn't you use a decent programming language, such as Lisp, where
> you could directly write source-code syntax for a data structure which
> was a map between the two versions of the data:
> (defparameter namint
>  '(("blah" . 1)
>    ("duhh" . 2)
>    ...
>    ))
> and then func1 and func2 would be nothing more than wrappers around
> assoc and rassoc respectively? Then if you ever discovered you needed
> the table to be runtime configurable by simply editing a text file, you
> could cut&paste the list of pairs from the source file to a standalone
> configuration-data file, and a simple READ and assignment to namint
> would put the latest version into use, not a line of actual code (func1
> or func2) would need to be changed. And if the list got very long and
> started taking significant time to search linearily down the list, you
> could "compile" the table into a simple lookup array in one direction
> and a binary-search array in the other direction, without changing the
> syntax of the configuration-data file hence not needing to re-train any
> staff whose duties included maintaining that table.

Or, if no-ones going to look in the file, then you can make the file a
lisp program.  To form the data structure the program is executed.
That way if the representation of the data on file is changed the only
thing that needs to change is the program that writes this program out.

(This also assumes you don't care about security)

.