title: How to parametrize my exports?
body: <p>I'd like to be able to parametrize my exports not only with types (as in, <em>generic exports</em>), but also with values.</p>
  
  <p>Something like:</p>
  
  <pre><code>    class Greeter
      {
          readonly string _format;
          public Greeter( string format ) { _format = format; }
  
          public string Greet( string name ) { return string.Format( _format, name ); }
      }
  
      // ...
  
      var e = new ExportProvider();
      e.ExportParametrized&lt;Greeter&gt;( args: new[] { "Hi, {0}!" } );
      e.ExportParametrized&lt;Greeter&gt;( args: new[] { "¡Hola, {0}!" } );
  
      // And then:
      [ImportMany] IEnumerable&lt;Greeter&gt; Greeters { get; set; }
  
      foreach( var g in Greeters ) Console.WriteLine( g.Greet( "John" ) );
  
      // Should print out:
      //   Hello, John!
      //   ¡Hola, John!
  </code></pre>
  
  <p>One might ask: why don't I simply export the value <code>new Greeter( "Hello, {0}!" )</code> using <code>ComposablePartExportProvider</code> and <code>CompositionBatch</code>?<br>
  While this approach would work in this particular case, it has an important flaw: if the <code>Greeter</code> class had any imports of its own, they would not be satisfied.</p>
  
  <p>The usual way I would go about this is to declare two classes - <code>EnglishGreeter</code> and <code>SpanishGreeter</code>, inherit them both from <code>Greeter</code>, and then provide the appropriate arguments in the call to base constructor.</p>
  
  <p>But this doesn't work for two reasons:</p>
  
  <ol>
  <li>This is a lot of noise to write. Not only do I have to type the whole shebang, I also have to come up with <strong>names</strong> for those classes, and it doesn't always make sense to have names. Not to mention the DRY principle. But even besides the noise...</li>
  <li>Sometimes I don't know the parameters upfront. Say, for example, my greeting formats were coming from some kind of config file.</li>
  </ol>
  
  <p><strong>Here is another thought</strong>, to somewhat clarify what I'm looking for.<br>
  This problem is <em>almost</em> solved in the <code>TypeCatalog</code>. See, the <code>TypeCatalog</code> knows about the type and it calls the type's constructor to create the part on demand.<br>
  One can think of this process from another standpoint: the catalog has a factory function; using that function, it creates the part, then satisfies its non-prerequisite imports, and then returns the part back to the requestor.<br>
  Now, in the particular case of <code>TypeCatalog</code>, the factory function just happens to be the type's own constructor. If only I could hook in and replace the factory function with my own, but still leverage the rest of the machinery, that would be exactly what I'm looking for.</p>