In hindsight, a better title should have been obvious. Good point @ITwrx.
I do my programming projects at the hobbyist level with no real computer
science background, just some introductory programming classes. With that being
said, I didn't really understand the point @Araq was making, but it started
become clear after reading the post @Isofruit made. If my understanding is
correct, I thought that it might be misunderstood that this is something that I
wanted to use all the time. My planned use case would only be when getting text
input from some source and referencing data based on that. I did that a few
times this year with the Advent of Code challenges. A brief example of what I
did is posted below. With an object with many fields this way essentially
doubles everything and I was looking for a way to change the object without
having to also change the referencing proc with each iteration. Two options
would be to have a "failsafe" as the last line shows (thanks to the else),
which may lead to false conditions that "look good" or check for expected input
and raise an Error with the else. While the failure mode is new, I don't see
the difference in doing this and referencing a key in a Table that doesn't
exist or an index in a Seq that is out of range. In the end, doesn't it end up
being the programmer's responsibility to scrub/validate the input to keep that
from happening anyway? And while being different names, the errors are
essentially the same?
type
OPerson = object
name:string
title:string
location:string
var p = OPerson(name:"Alpha", title:"Worker", location:"Metropolis")
proc getField(p:OPerson; fld:string):string =
case fld
of "name": p.name
of "title": p.title
else: p.location
doAssert p.getField("name") == "Alpha"
doAssert p.getField("title") == "Worker"
doAssert p.getField("location") == "Metropolis"
doAssert p.getField("nothing") == "Metropolis" #This field doesn't exist
Run
