Question of the Day — What’s Worse?

Instead of “constraints on new”, I think a much nicer pattern is to pass a delegate whose job it is to construct the thing. Here’s some code which requires a constructor of signature (int,string):

Sub f(Of T)(ByVal f As Func(Of Integer, String, T))
Dim newlyConstructedObject = f(1, “hello”)
End Sub

Sub Main()
f(Function(i, s) String.Format(“{0}:{1}”, i, s))
End Sub

This way is more flexible because accessibility of the delegate is as it was at the callsite of the generic function where it’s supposed to be. Also it supports the object-initializer idiom.

Could you give a complete sample of the sort of thing you want where type inference doesn’t work today? I tried this code, which I thought at first was similar to what you want, and it inferred fine, so I must be missing something.

public static class Program
{
static void Main(string[] args)
{
var x = new System.Collections.Generic.List();
var y = x.Map((i) => i.ToString()).Map((s) => System.Int32.Parse(s));
}

static System.Collections.Generic.IEnumerable Map(this System.Collections.Generic.IEnumerable x, System.Func f)
{
return new System.Collections.Generic.List();
}

}

Cannot say that generic constraints have ever offended me to be honest.. so to me this is a bit confusing.

Unless you want your users experiencing bizarre errors are JIT time (or give up the ability to have generic class definitions in separate assemblies), there is really no way around generic constraints.

@Jeremy: I agree completely that better type inference would be a welcome improvement. Further, that type of improvement is preferable because it mostly affects the compiler and does not significantly alter the language specification.

Aside from the performance issue regarding methods being virtual by default, there is the issue of versioning. In a perfect world, developers would never forget to seal methods that should not be overridden and would not expose methods as virtual if altering the behavior could break the functionality of the class. Unfortunately, that is a long shot from reality. We can certainly agree to disagree, but I believe that having methods sealed by default results in more maintainable code, particularly when that code is written by junior developers.

@Mike Strobel,

Thanks for the comment.

In regards to Generics, it’s stuff like:

public void Do() where T : new() — forget this. I don’t want to have to define that constraint

THIS CODE:

ForController(“home”)
.Map(c => c.Index()).ToView()
.Map((c, input) => c.Dashboard(input)).ToView()
.Map(c => c.UserWorkflowData()).ToJson()
.Map((c, i) => c.MyTaggedItems(i)).ToJson()

The call to Map(Func func), I want type inference here by default the way it can with a simple arguments.

“As for making all methods and properties virtual by default, I urge you to consider the performance ramifications.”

I’m aware of the arguments for the sealed by default argument, and I’ve never bought into the performance argument. There’s far more very large systems built with Java where it’s virtual by default, and they’re doing fine. I think the tax on productivity and code noise is more important than a very minor performance optimization