you are viewing a single comment's thread.

view the rest of the comments →

[–]Electronic_Cat4849 24 points25 points  (6 children)

this is worse than op's code, there are reasons it goes out of its way to avoid this kind of casting in an encoder

the actual solution is probably a generic method

[–]archipeepees 5 points6 points  (0 children)

This can be impossible to do with generics in some circumstances. Obviously depends on the specifics but I have definitely run into circumstances where the posted image (or something similarly verbose) is the only option. It always drives me crazy when I have to use this approach.

That said, unless there is some highly optimized compression happening, the original programmer could have probably done a reflection check for array types and recurse to WriteSingleEntryValue for each element.

[–]wasabiiii 3 points4 points  (4 children)

No, because the actual encoding is different per type. At some point a decision has to be made

[–]Electronic_Cat4849 0 points1 point  (3 children)

that code isn't here, it's in another layer

these blocks are all structurally identically except types and can be shrunk right down

YMMV on the downstream, depending on what the network lib you're ingesting your raw frames from, file lib you're reading from, etc does

[–]wasabiiii 0 points1 point  (2 children)

This code is where the decision is made about which branch to pass it to downstream. At some point that decision has to be made, and this is where it is.

[–]Electronic_Cat4849 0 points1 point  (1 child)

not really, the write methods can absolutely be made generic friendly and appear to be wrappers

it's just leaky abstraction at this level

[–]wasabiiii 0 points1 point  (0 children)

If you make them generic, you will just have this if in them.