Ayende @ Rahien

Ayende Rahien commented on Fluent Pipelines

Mon, 07 Jan 2008 11:27:10 GMT

Jon, Wow! implicit delegate conversions will be put to a cool use.

Ayende Rahien commented on Fluent Pipelines

Mon, 07 Jan 2008 11:25:42 GMT

Jon, Using delegate prevents me from dealing with the operations in a smarter way. Take a look at the code there. We are passing context into the operation, which is can make use of. With the delegate trick, we can do make it seamless to the outside, while retaining the power in having full blown classes, rather than function pointers.

Jon Skeet commented on Fluent Pipelines

Mon, 07 Jan 2008 10:19:19 GMT

Just tried, and you can indeed write an implicit operator converting to a delegate. Jon

Jon Skeet commented on Fluent Pipelines

Mon, 07 Jan 2008 09:04:25 GMT

Oh, quick other comment if you ever want to put complete code here with minimal extra classes - GenerateData is already implemented as Enumerable.Range(). I haven't found it particularly useful yet outside sample code, but it's nice to know about just in case :)

Jon Skeet commented on Fluent Pipelines

Mon, 07 Jan 2008 09:02:42 GMT

You correctly mentioned the idea of a DelegateOperation in the original discussion, as a way of using delegates when you want to (although it means even simple things end up having a lot of fluff around them). The same is true the other way round here - you can still have your SqlBulkInsertOperation and your FibonacciBulkInsert, with a public method with the appropriate signature, and either create a delegate directly from the relevant method or use a lambda expression to call it to avoid the cast. (I can now see how the bug around output type inference could be a problem...) So, four examples of code: Example 1: // (Not good if creating a new FibonacciBulkInsert takes time) var pipeline = ... .ForEach(item => new FibonacciBulkInsert().Action(item)); Example 2: SqlBulkInsert inserter = new FibonacciBulkInsert(); var pipeline = ... .ForEach(item => inserter.Action(item)); Example 3: var pipeline = .ForEach((Action) new FibonacciBulkInsert().Action); Example 4: Action insertAction = new FibonacciBulkInsert().Action; var pipeline = ... .ForEach(insertAction); If output type inference worked, of course, we could just do: var pipeline = ... .ForEach(new FibonacciBulkInsert().Action); I can't remember offhand whether you can define implicit conversions from a class to a delegate type. If you could, you *could* put one on SqlBulkInsert (or a suitable abstract base class) to Action, then do: var pipeline = ... .ForEach(new FibonacciBulkInsert()); which is pretty much your original code. I'm not sure I'd recommend it even if it's feasible though - I don't like implicit conversions. It really seems to me that the two approaches are just different angles on exactly the same thing. I like the fact that MS has done a lot of the grunt work around Select, Where, SelectMany etc for me :) It looks like it's also a case of optimising syntax for the simple cases or optimising syntax for complex cases. The right choice there depends on what you're doing, of course :) Jon