…l’intellisense :-)
Questo test è meraviglioso, generics e anonymous types alla massima potenza:
[TestMethod]
public void asyncWorker_expecting_anonymous_type_as_result_should_correctly_set_result()
{
    var wa = new ManualResetEvent( false );

    var expected = "result";
    var actual = "";

    var worker = AsyncWorker.Using( expected )
        .AndExpecting( new { Sample = "" } )
        .Configure( cfg =>
        {
            cfg.After = e => actual = e.Result.Sample;
        } )
        .Execute( e => e.Result = new { Sample = e.Argument } );

    worker.Completed += ( s, e ) => wa.Set();
    wa.WaitOne();

    actual.ShouldBeEqualTo( expected );
}
con “AndExpecting()” definito così:
public interface IInputWorker
{
    IConfiguredInputWorker Configure( Action<IInputWorkerConfiguration> cfg );
    IWorker Execute( Action<IAsyncArgs> async );

    IInputOutputWorker AndExpecting();
    IInputOutputWorker AndExpecting( TResult sample ); 
}
Sempre perchè anche la coding experience vuole la sua parte… un po’ come l’occhio :-)
A che scopo?
Semplicemente evitare la creazione di una tupla/dto in molti contesti in cui gli anonymous type(s) sono una soluzione ottimale.
L’inghippo è che con i generics siete obbligati a specificare il tipo T (in questo caso TResult) ma non è possibile specificare come tipo T un anonymous type; è però possibile, come evidenziato dal test, ingannare l’intellisense sfruttando la “Type Inference”: in questo caso passiamo al metodo AndExpecting() un tipo anonimo al solo fine di stimolare la Type Inference e far si che il tipo della proprietà “Result” abbia la stessa firma del tipo che abbiamo usato come esempio…
figo :-)
.m