7

I've created a generic class that needs to instantiate its implementation type, so the implementation type has to have an accessible parameter less constructor. Looks like the new() restriction could do the job but its enforcing the implementation type to have a public constructor when I have it internal (but accessible as both are on the same assembly).

  1. Is there a reason to force it to be public rather than "accessible"?
  2. Is there a way to do what I need?

Thanks in advance.

EDIT: The reason to do this is that I have a class X that must be used through a Singleton. The Singleton class is a generic class and I want to make the class X constructor internal to avoid external users accessing the object in a wrong way (calling the constructor).

Ignacio Soler Garcia
  • 21,122
  • 31
  • 128
  • 207

3 Answers3

6

This is disallowed by the C# language as outlined in section 4.4.3 of the specification Bound and Unbound Types.

If the constraint is the constructor constraint new(), the type A must not be abstract and must have a public parameterless constructor. This is satisfied if one of the following is true.

  • A is a value type, since all value types have a public default constructor
  • A is a type parameter having the cosntructor constraint
  • A is a type parameter having the value type constraint
  • A is a class that is not abstract and contains an explicitly declared public constuctor with no parameters
  • A is not abstract and has a default constructor.

A compiler error if any one of these conditions are not met. If you find yourself having types that are public but only with internal constructors, then most likely they should actually be internal types with public constructors.

I would recommend changing your types accessor to internal and its constructor's to public, and make it parameterless. Your public parameterless constructor could then call through to a non-parameterless private or internal constructor to do any additional initialization work.

internal class C<T> where : T new()
{
    public C() : this(new T()) {
    }

    private C(T t) {
        // Do additional initialization
    }
}

Mind you that pattern is limited, but there's nothing stopping you from using a private method instead.

internal class C<T> where T : new() {
    public C() {
        T t = new T();
        InitializeClass(t);
    }

    private void InitializeClass(T t) {
        throw new NotImplementedException();
    }
}   

As per your update, here's a small example of a public singleton patter.

public class Singleton<T> where T : new()
{
    public static Singleton<T> Current {
        get;
        private set;
    }

    internal Singleton() : this(new T()) {
    }

    private Singleton(T t) {
        Current = this;
        // Do whatever you need to with T
    }        

    public String Name {
        get;
        set;
    }
}

Usage

// Somewhere in your internal assembly
Singleton<String> singleton = new Singleton<String>();

// In an external assembly
Singleton.Current.Name = "SoMoS";

You don't even need to use constructors in that fashion either, you can just as easily do something simple.

public class Singleton<T> where T : new()
{
    public static Singleton<T> Current {
        get;
        private set;
    }

    internal Singleton() {
        T t = new T();
        // Do stuff with T
    }

    public String Name {
        get;
        set;
    }
}

Generics may not be the way to go if you can't design it to fit your requirements. Generics can only do so much and don't solve every problem. There are things like Factory Pattern, Injection, etc..

Community
  • 1
  • 1
David Anderson
  • 13,558
  • 5
  • 50
  • 76
2

Is there a reason to force it to be public rather than "accessible"?

Term accessible is very context sensitive, generics are not, by architecture. In your specific case internal could be accessible, but generics are made for generic solutions.

Is there a way to do what I need?

Based on first point, no, it's not possible, nor that I'm aware of.

RJFalconer
  • 10,890
  • 5
  • 51
  • 66
Tigran
  • 61,654
  • 8
  • 86
  • 123
  • Well, to my point of view the compiler could check at compile time if the constructor will be accessible or not an raise an error only if the new cannot be called from the generic class. Anyway, thanks for the explanation. – Ignacio Soler Garcia May 11 '12 at 12:55
  • @SoMoS: The problem is that a type `T` which has a `new()` constraint may well be passed to routines in different assemblies. While it might be possible for a compiler in some cases to determine that a particular type parameter `T` could never be passed outside a particular assembly, in many cases such inference is not possible. Allowing types with `internal` parameterless constructors to satisfy `new()` constraints only when the compiler could infer that it would be safe would imply having rather odd rules for when such usage was permissible. – supercat May 11 '12 at 20:05
  • @SoMos: what you are asking for, is some special `internal new()` definition, where you can define It esplicitly. Why do not infer it now? I think it's about types sharing between different assemblies. What should happen if I want to use a generic of some runtime type whom ctor is not accessible from "outside".... – Tigran May 11 '12 at 20:12
  • @Tigran: of course what always happen when something is wrong at runtime, raise an exception. I really don't see why this constraint is enforced at compile time instead of doing it at runtime. – Ignacio Soler Garcia May 12 '12 at 08:26
  • 1
    @SoMoS: may be becasue, like Eric Lippert usually says: "because none it implemented" :) – Tigran May 12 '12 at 09:45
1

Generics are for generic solution, therefore if you use the "new" constraint, your solution have to work with every class which implements a public ctor.

If you want to implement a generic solution for a specific kind of classes you can define an abstract base class which implements a such internal constructor. Implement a generic solution for this abstract base class and use

* where T : MyBaseClassWithInternalCtor *

as constraint.

Manuel Amstutz
  • 1,311
  • 13
  • 33