4 ms·
So this all arose because you added a "type" field to your structs and then wrote a lot of code to do type switches. Finally, you realized Go already has this f
by timtadh 15y ago
So this all arose because you added a "type" field to your structs and then wrote a lot of code to do type switches. Finally, you realized Go already has this functionality. Note Go makes your life even nicer than you think.
your code:
v := eval(e)
switch v.(type) {
case cons:
fmt.Printf("<cons>\n")
case sym:
fmt.Printf("<sym : %s>\n", string(v.(sym)))
case float64:
fmt.Printf("%f\n", v.(float64))
case string:
fmt.Printf("\"%s\"\n", v.(string))
default:
fmt.Printf("nil\n")
}
now without the redundant type assertions.
switch v := eval(e).(type) {
case cons:
fmt.Printf("<cons>\n")
case sym:
fmt.Printf("<sym : %s>\n", string(v))
case float64:
fmt.Printf("%f\n", v)
case string:
fmt.Printf("\"%s\"\n", v)
default:
fmt.Printf("nil\n")
}
It seems like your problem isn't that you don't "trust your tools" it's that you don't known them. That's fine. I don't really know half of mine half as well as I should. Programmers not understanding their tools is a long studied problem with no good solution.
- srl 15y agoI do know my tools, actually (having helped create them) - before creating the structs, I did consider this approach, and consciously decided against it for roughly the reasons described. I'm talking about a distinct problem from programmers not knowing their tools - programmers who do know and understand their tools quite well, but decide, for whatever horrible reason, that those tools are "quite good enough", and insist on going from scratch. Sometimes justified, and usually not - and it can lead to a great deal of harm in the way of unmaintainable bloat.
- omaranto 15y agoI think timtadh's jab about you not knowing your tools wasn't about the structs with a type field but about the .(float64) in case float64: fmt.Printf("%f\n", v.(float64)) which can be simplified to case float64: fmt.Printf("%f\n", v)
- deleted 15y ago[deleted]
- andrewflnr 15y agoProgrammers not understanding their tools is a long studied problem with no good solution. As is the problem of programmers not trusting their tools. I think they're both still worth writing about every now and then. In fact, that might be the closest thing to a solution we have. Hopefully every time you bring it up, a few more people get it.