RFC Support a namespace via config

[dantswain]

Using namespace elixir MyStuff in the .thrift files produces a pile of warnings along the lines of

[WARNING:/some/path/my_struct.thrift:6] No generator named 'elixir' could be found!

whenever running the official thrift compiler to generate code for another language.

This can be disabled by using -nowarn but that suppresses all warnings, which seems like a bad idea.

I think supporting the namespace keyword is fine, but there's something wonky to me about requiring people to opt in to a pile of warnings in their pre-existing workflow. One way to get around this would be to make the namespace keyword optional and support a namespace option in the compile step configuration (see #194 - thrift: [namespace: MyStuff, input_files: ...]).

[jparise]

I think this is a good suggestion. There's one part of the behavior that I think still need some specificity, though. When a top-level namespace option is configured and we encounter a namespace keyword in a .thrift file, should we:

1. Use the file's namespace, overriding the top-level compiler option
2. Use the top-level compiler option, ignoring all file-level namespaces
3. Append the file-level namespace to the top-level namespace

I think 1 is the more obvious, but I can see arguments for the others.

We could also make the top-level namespace compiler option do fancy things like per-file overrides when e.g. a map or function is given instead of a string, but that's probably more complicated than we actually need.

[dantswain]

I also like 1. I ran into this because I added elixir namespaces to some of our thrift files and now people are asking me about the warnings. It would solve my problem if I could just specify the namespace as an option, and having it overridable at the file level would still give people flexibility.

Another option would be to be able to specify groups of files -

def project do
  thrift: [
    namespace: [Namespace1: ["foo.thrift", "bar.thrift"], Namespace2: ["baz.thrift"]]
  ]
end

That may be overcomplicated though.

[pguillory]

What if we supported elixir namespaces in comments? So other compilers would ignore it.

namespace cpp whatever
namespace java com.universe.milkyway.earth.whatever
#namespace elixir Whatever

Kind of a hack, but on the other hand #define wasn't the end of C.

[jparise]

What if we supported elixir namespaces in comments?

That's a creative solution, but after thinking about it a bit, and I'm 👎 on it because:

1. It makes our parsing rules more complicated, and we'd be setting precedent for supporting other directives using this syntax.
2. It still leaves a gap for the case where a .thrift file hasn't been modified to specify a namespace, so we'd still need a global default to provide that value.

[jparise]

Closed via #225