Richard Bucker

reflection on golang reflection

Posted at — Jun 6, 2015

I’m building a transaction gateway that requires the transcoding message from one schema to another. The messages will originate from the client as a JSON string which is easily parsed by the stdlib and then transcoded to a bytestream based on some schema. The server will process the transaction and return another byte stream which must be parsed according to some schema and then transcoded back to a JSON string and returned to the client.My challenge, as I review the encoding packages, is how or where do I store the DDL (data definition language) for the byte streams? One easy representation is in the golang struct with the schema contained somewhere in the field types and the tags.The question, however, is it better to use reflection at runtime or precompute some DDL from the struct or just manually construct the DDL?Some weeks ago I reviewed some code for an ISO8583 encoder. It did a good job of parsing messages into it’s perspective fields, however, in their implementation the user had to provide the schema with every transaction and the first thing the parser did was compute a DDL which it discarded after the parsing was complete. While correctness and clarity are job #1; this explains their decision.Looking at the stdlib version of the JSON Unmarshal() code I see that they rely on reflection. Quickly reviewing the ffjson package for unmarshal’ing I have no idea what they have done. I do see that they implemented a generator of sorts, however, the public API layer is so obtuse that it feels like this might have been implemented in another language and ported to go. (not a bad thing) but there is a lot more code than the stdlib so it’s a matter of complexity over getting the work done.For now the answer is “working”. Fast is a nice problem to have… just not now.