Allow disabling code-generation for individual types

[2opremio]

This is inspired by // ffjson: skip

There are situations in which the user needs/wants to provide custom Selfers for some of the types declared in a file while still being able to automatically generate Selfers for the the rest of the types in that file.

For instance see weaveworks/scope@23ddc1b

I couldn't find an acceptable way to do this with the existing implementation:

• The -r parameter of codecgen is not good enough for excluding types. Regexps are not well suited for negative matching of words. On top of that, Go's regexp implementation intentionally doesn't support lookaheads to comply with its O(n) matching promises, which makes it particularly hard (see http://stackoverflow.com/questions/2078915/a-regular-expression-to-exclude-a-word-string and https://groups.google.com/d/msg/golang-nuts/7qgSDWPIh_E/OHTAm4wRZL0J )
• I could have split the files in two (types with custom selfers and types without) but this is a horrible solution: structuring the code based on the requirement of a tool.

[ugorji]

ffjson uses comments to control behaviour. go-codec doesn't as a matter of design principle. For that reason, using comments will have a very high barrier for consideration/acceptance.

I would be willing to do a not-match flag i.e. only include types which "match" the "match" regex and "do not match" the "not-match" regex.

I understand the limitations of the golang regex package: however, we will live with it, as that is not the core of the go-codec solution.

Your options are:

• using the flag (with possibility of adding a -nr flag)
• splitting the files

Both of these are workable solutions. They are not ideal, but I think (from the POV of the design of go-codec) that using comments is a non-starter. Using comments here will be a one-off solution that feels foreign to the solution - like it was tacked on.

[2opremio]

I find the -nr approach very inconvenient. It requires book-keeping type-names, which is particularly bad if you are not using go generate since it involves handling type-names outside of sourcecode. But ... your project your rules :). At least it's better than breaking the files in two.

Closing in favor of #140