Proposal: Metaclasses

[msfcolombo]

Smalltalk-80 introduced metaclasses, and Delphi made them elegant enough. See also here.

The following examples explain a metaclasses proposal for C#.

Metaclasses vs Factory classes

Without metaclasses, we are forced to develop factory classes:

class Animal {}
class AnimalFactory {
    virtual Animal Create() { return new Animal(); }
}

class Dog: Animal {}
class DogFactory: AnimalFactory {
    override Animal Create() { return new Dog(); }
}

// inside some method body:
AnimalFactory factory = new DogFactory();
Animal myPet = factory.Create(); // Returns a Dog instance.

With metaclasses, the class itself can be a factory:

class Animal {
    // "static virtual" is supported from metaclass specification.
    static virtual Animal Create() { return new Animal(); }
}

class Dog: Animal {
    // "static override" is supported from metaclass specification.
    static override Animal Create() { return new Dog(); }
}

// inside some method body:
meta Animal factory = typeof(Dog); // Returns an object of type `meta Dog`, compatible with `meta Animal`.
Animal myPet = factory.Create(); // Since factory is meta Dog, this calls Dog.Create(), therefore returns a Dog instance.

The clear advantage is reducing and simplifying the set of classes. Another advantage is that since static methods can access private non-static members, there is less exposure of implementation details that would otherwise be visible to factory classes.

Metaclasses vs Singletons

Without metaclasses, one needs to verbosely describe singleton instances and prevent objects from being instantiated with a private constructor:

interface ICryptoAlgorithm {
    byte[] Encrypt(byte[] data);
}

class Sha256: ICryptoAlgorithm {
    public static ICryptoAlgorithm Instance = new Sha256();
    private Sha256() {}
    public byte[] Encrypt(byte[] data) { ... }
}

// insde some method body:
ICryptoAlgorithm algo = Sha256.Instance;
ciphertext = algo.Encrypt(plaintext);

With metaclasses, there's no need for the singleton pattern verbiage:

static abstract class Crypto {
    static abstract byte[] Encrypt(byte[] data);
}

static class Sha256: Crypto {
    static override byte[] Encrypt(byte[] data) { ... }
}

// insde some method body:
meta Crypto algo = typeof(Sha256);
ciphertext = algo.Encrypt(plaintext);

Metaclasses vs Attributes and Reflection

Without metaclasses, one can use attributes or reflexive members as way to capture class-specific information:

// Example using attributes:
[Description("Allows user type text in a form.")]
class EditBox: Widget {
}

// Example using reflective members:
class EditBox: Widget {
    public static string GetDescription( string cultureId )
    {   switch (cultureId)
        {
            case "EnUs": return "Allows user type text in a form.";
            case "PtBr": return "Permite ao usuário digitar texto num formulário.";
            default: return null;
        }
    }
}

Attributes have the disadvantage of being non-flexible - the value cannot change after compilation. They are also an additional artifact. Reflection solves that problem, but makes code difficult to read, as the editor can't find any reference to a member accessed through reflection.

Metaclasses solves both issues:

class Widget {
    static virtual string GetDescription( string cultureId ) {}
}

class EditBox: Widget {
    static override string GetDescription( string cultureId ) { ... }
}

// inside some method body:
meta Widget widgetType = typeof(EditBox);
var description = widgetType.GetDescription("EnUs");

Specification draft

• For each class Foo, there is optionally an additional type called meta Foo, which is the metaclass of Foo.
• The type meta Foo is derived from System.Type. Therefore, a variable of type meta Foo can be used to retrieve type name, assembly, etc.
• The expression typeof(Foo) returns an object of type meta Foo. Since that derives from System.Type, there is no hard compatibility break.
• If Bar derives from Foo, then meta Bar derives from meta Foo.
• The base type of all metaclasses is System.Type.
• An instance of meta Foo can be used to access static members of Foo.
• Class Foo can have overridable static members. The access Foo.Member is static, however the access ((meta Foo) someObject).Member is polymorphic. This is the key feature of metaclasses.
• For a given type Foo, the compiler only generates a metaclass if Foo declares some overridable static member, or if some base class is generating a metaclass. This prevents cluttering the assembly with unused types.
• The compiler reports an error if the keyword meta is used with a class that does not produce a metaclass.

[iam3yal]

@msfcolombo

The clear advantage is reducing and simplifying the set of classes.

So you want to move the responsibility from the factory to the classes that only need to have knowledge of one thing and focus on one thing and that is representation? why reducing and simplifying the set of classes is a clear advantage? it might be a clear advantage when you don't mix responsibilities, otherwise; I'd say it isn't.

Another advantage is that since static methods can access private non-static members, there is less exposure of implementation details that would otherwise be visible to factory classes.

Factories shouldn't know anything about how things work and if they do then it's a design smell; if there's a leak in the implementation it might mean that this class is doing too much and may need to be refactored.

Besides, allowing subclasses to know about their parents may break the inheritance chain. inheritance is already a strong relationship and you wouldn't want to make this relationship even stronger by essentially turn every inheritance into a God object.

Besides this I don't know how virtual and static fits together, what would it mean in terms of implementation?

[Thaina]

There are extension static member and static interface that would easily enable factory implementation on any class and I think that would be better

[svick]

It seems to me that shapes (#164) would solve this problem, even if they use different syntax (types are passed out as generic parameters, not as values).

[msfcolombo]

@eyalsk

why reducing and simplifying the set of classes is a clear advantage?

The complexity of a system is a function of the number of parts. Less parts means less complexity. Less files to control version, less code to review, etc. Of course a component can become cluttered, but the specification is not prohibiting developers to build factory classes. :-)

Factories shouldn't know anything about how things work and if they do then it's a design smell

Yeah, right. And the internal keyword is useless. Again, the spec is not prohibiting anyone to properly protect their code. Metaclasses are just a new tool. People can use if deemed necessary, and Delphi folks did that in a very successful way at the VCL. It's a great alternative to reflection.

allowing subclasses to know about their parents may break the inheritance chain

Can you elaborate? I don't see any difference between a subclass overriding a non-static method (as allowed today), and overriding a static method, provided the base class properly declare the method as virtual.

[iam3yal]

@msfcolombo

The complexity of a system is a function of the number of parts. Less parts means less complexity. Less files to control version, less code to review, etc. Of course a component can become cluttered, but the specification is not prohibiting developers to build factory classes. :-)

You reduce the overall complexity in the expense of increasing the coupling between classes and also lower their cohesiveness so I don't think that this is a good trade off in terms of maintenance.

Yeah, right. And the internal keyword is useless. Again, the spec is not prohibiting anyone to properly protect their code. Metaclasses are just a new tool. People can use if deemed necessary, and Delphi folks did that in a very successful way at the VCL. It's a great alternative to reflection.

Just because a type is marked with internal doesn't mean other types should be dependent on this type directly.

I'll cite you:

Reflection solves that problem, but makes code difficult to read

A solution exists, the other part can be solved through a library, isn't?

as the editor can't find any reference to a member accessed through reflection.

Use nameof instead of plain strings.

Can you elaborate? I don't see any difference between a subclass overriding a non-static method (as allowed today), and overriding a static method, provided the base class properly declare the method as virtual.

In C# instance method calls are polymorphic whereas static method calls aren't so what exactly does static virtual/abstract mean?

[msfcolombo]

@eyalsk

You seem to be new to the concept of metaclasses in OO world. You should check Smalltalk, Delphi, Python, Objective-C and TypeScript. They all support metaclasses in one way or another. I picked Delphi style because IMO it's the most elegant and compatible with C#, and is extremely successful.

That said, I do agree that #164 might replace metaclasses, although the scope of that is much greater than this, in one or two orders of magnitude.

Now to your comments!

You reduce the overall complexity in the expense of increasing the coupling between classes and also lower their cohesiveness so I don't think that this is a good trade off in terms of maintenance.

There is no such thing as "between classes", because instead of factory and item classes, you have a single class definition - the item class. Note that any static method is already allowed to access private members. Therefore there is no increased coupling.

Just because a type is marked with internal doesn't mean other types should be dependent on this type directly.

I'm not talking about internal types, I'm talking about internal members. There are a lot of them, just check .NET code. They are useful because in real word, you can't fully prevent all related classes from accessing hidden members of each other. Real world scenarios are more complex than purism can support. C# solves that with internal, Java solves that with package visibility. Of course it must not be used lightly.

In C# instance method calls are polymorphic whereas static method calls aren't so what exactly does static virtual/abstract mean?

Ok, it seems that here is where lies the greatest pain point.

Regarding a method definition, there are two dimensions to consider: scope and type resolution (of course there are other dimensions like visibility, but those are irrelevant in this discussion).

• The scope dimension tells if the method is static or non-static. A static method can be called in any scope. A non-static method can only be called under the scope of an instance.
• The type resolution dimension tells if the method is virtual or non-virtual. The type resolution of a virtual method is performed during execution. The type resolution of a non-virtual method is performed at compilation. Note that abstract and override are just variations of virtual (ie, an abstract or overriden method call is just a virtual method call).

These two dimensions are independent, giving four combinations:

• static non-virtual
• static virtual (not supported by C#)
• non-static non-virtual
• non-static virtual.

The fact that C# doesn't support static virtual is a limitation accepted from the fact that Java doesn't support either. It's indeed useless because static virtual only makes sense for metaclasses, which are not supported by C# and neither Java.

Some people talk "if is static, it can't be virtual, doesn't make sense!!!". This comes from the wrong assumption that static tells more than the scope dimension, which is not true. You can call a static method using reflection, and if the #164 becomes real, you will be able to call using the generic type parameter. All this means that a static call can be polymorphic - oh, the world is doomed!!! Also, if a method is non-virtual and non-static (an ordinary instance method), we say in C++ verbiage that the method is statically linked - the destination type is known at compilation. If you see machine code for the C# call foo.SomeMethod(args), you will find TypeOfFoo::SomeMethod(foo, args) - yes, that's a static call for a non-static method.

Delphi Object Pascal, which was designed by Anders Hejlsberg, avoided the static keyword for the scope dimension. Instead of static, he used the class keyword:

// Delphi code:
type Foo = class(BaseClass)

    procedure SomeInstanceMethod( x: Integer );
    class procedure SomeStaticMethod( x: Integer );

end;	

The above is 100% equivalent to C#:

// C# code:
class Foo: BaseClass {

    void SomeInstanceMethod( int x) { ... }
    static void SomeClassMethod( int x ) { ... }
	
}

As you can see, Delphi removes all confusion surrounding the static term. IMHO, Delphi respects lectures better, as "static linking" traditionally also applies to instance methods. A virtual method invocation used to be called a dynamic dispatch, and it doesn't matter if the scope is class or instance.

Since Delphi does support metaclasses, it also does support static virtual - yes, it's been 20 years since Delphi supports all four combinations! There is only the idiomatic and syntactic difference - methods are called "class methods" there, not "static methods".

Frankly, I don't care much if C# will ever support metaclasses. I just wanted to add it to discussion. The shapes proposal looks superior indeed, but there are far more challenges to get that working. Metaclasses are much less risky and can be an alternative if shapes get into some blocking issue, or if it gets trimmed down to a point where metaclasses are still relevant.

[HaloFour]

@msfcolombo

static virtual is a little more involved than that. You need a vtable, which needs to be attached to an instance of something. The vtable defines which actual method gets called. There is no vtable for types, nor is there an instance on which the vtable to be defined, so there's nothing that the runtime can use to virtually dispatch the call. This isn't a C# limitation, it's a CLR limitation.

That said, a language like C# can work around that limitation. Oxygene does, for example, support metaclasses. It does so by emitting two types for every class, the class itself and the metaclass on which the static members are defined as virtual instance members. When inheriting from that class an additional two classes are created, and the metaclass overrides those virtual instance members. When you pass the metaclass around you're actually passing an instance to the metaclass type, and when you invoke its "static" methods you're making virtual calls on that instance. It serves Oxygene but of course it's not at all seamless to other languages.

I'm sure that you mentioned Anders due to his role in designing both Object Pascal and C#. It's not like C# was designed in ignorance of metaclasses.

[iam3yal]

@msfcolombo

You seem to be new to the concept of metaclasses in OO world. You should check Smalltalk, Delphi, Python, Objective-C and TypeScript. They all support metaclasses in one way or another. I picked Delphi style because IMO it's the most elegant and compatible with C#, and is extremely successful.

I'm not new to the concept, I just can't see the value in it.

There is no such thing as "between classes", because instead of factory and item classes, you have a single class definition - the item class. Note that any static method is already allowed to access private members. Therefore there is no increased coupling.

I meant that if you make calls from one class to another directly then you increase the coupling between them which most of the time isn't desired.

class A
{
	public static A Create()
	{
		return new A();
	}
}

class B
{
	A _a;
	
	public B()
	{
		_a = A.Create();
	}
}

Yes, static method can access private members given that the static method exists inside the class it creates an instance of so in this case you're right.

You can call a static method using reflection, and if the #164 becomes real, you will be able to call using the generic type parameter.

Yes, you can call static methods using reflection, what does it mean? does it mean that static methods are or can be polymorphic?

Can you elaborate how #164 solves the problem exactly? I know how it can be "solved" but don't understand what exactly "call using the generic type parameter" means.

static call can be polymorphic

Did I say otherwise? I said that in C# it isn't the case.

If you see machine code for the C# call foo.SomeMethod(args), you will find TypeOfFoo::SomeMethod(foo, args) - yes, that's a static call for a non-static method.

Yes I know that but I wouldn't really call it a static call, I mean as far as I know neither Assembly or IL have an explicit "static" instruction call but what's the point in this statement? I mean this fact alone doesn't provide any sort of polymorphism so how does it help?

Since Delphi does support metaclasses, it also does support static virtual - yes, it's been 20 years since Delphi supports all four combinations! There is only the idiomatic and syntactic difference - methods are called "class methods" there, not "static methods".

It's all great but C# isn't Delphi and then there's the CLR that I think doesn't support this but I could be wrong unless static virtual would be instance methods in disguise or something. :)

All in all there's much jargon and not an answer to this simple question: "A solution exists, the other part can be solved through a library, isn't?"

[msfcolombo]

@HaloFour

There is no vtable for types. (...) Oxygene (...) support metaclasses (...) by emitting two types for every class.

Please tell something new. If you actually read this spec, you may encounter things you find interesting:

• The expression typeof(Foo) returns an object of type meta Foo. There's your vtable.
• The metaclass inherits from System.Type. So it's a new generated type, just like Oxygene.
• The generation of the metaclass type is conditional to existence of static virtual, to avoid cluttering the assembly with useless types.

So yes, I did think on vtable. Anyway, thanks for going deep into this. Sometimes I miss this level of knowledge in these discussions.

It's not like C# was designed in ignorance of metaclasses.

I never said that. What I'm not sure is if metaclasses were left out deliberately, or due to budget limits. I would bet in the second alternative. It's clear that C# were designed to allow any Java code to be ported, as there is a 1-1 mapping to almost every Java feature! The object type even has hashcode! It would be nice if it allowed porting from other languages as well, such as the ones that support metaclasses!

[msfcolombo]

@eyalsk

I meant that if you make calls from one class to another directly then you increase the coupling between them which most of the time isn't desired.

Thanks Mr Obvious, but I can't see how this is related to this spec, as we are talking about a single class.

I'm not sure if you internalized the following idea: Sometimes people don't want to use the Factory pattern. There are cases where the Factory class is nothing more than a virtual method calling a constructor. The only reason to use a separate class is precisely the lack of metaclasses. Many factory classes are nothing more than manual implementation of a metaclass. This spec explicitly tells that without metaclasses, people are forced to use two classes, even if that is not required. Side note: among factory pattern and metaclasses, which concept do you think is older?

I just can't see the value in it.

I agree that the (overly exposed) simplification value might be low enough to left this out. But how about porting code from languages that support metaclasses? The capacity to accept migrations is an important value in any language.

Can you elaborate how #164 solves the problem exactly? I know how it can be "solved" but don't understand what exactly "call using the generic type parameter" means.

Consider the following call:

void SomeMethod<T>(int arg) where T: ISomeInterface, new() {
    var instance = new T();
    instance.CallSomeInterfaceMethod(arg);
}

SomeMethod<Foo>(123);

Without optimizations, this is roughly translated as:

void SomeMethod(System.Type T, int arg) {
    var instance = (ISomeInterface) Activator.CreateInstance(T);
    instance.CallSomeInterfaceMethod(arg);
}

SomeMethod(typeof(Foo), 123);

Did you note how the generic type parameter T became an actual parameter? The current limitation is that you can't call static methods. However with #164, we can have this:

void SomeMethod<T>(int arg) where T: SomeShape {
    var instance = T.SomeStaticMethod();
}

Repeating my previous comment, #164 allows a call to a static method through the generic type parameter. It became a polymorphic call without explicit use of reflection. Did you get it now?

There are still big challenges on #164, for instance, how to make binding quick enough, how to provide a fast reflexive version of SomeMethod? These issues are related to the fact that SomeShape is not a type, but a (potentially big) set of signatures that must be verified at runtime. Scala (which does support shapes - see structural types) solves that by creating an implicit interface for the shape, which is hidden from the developer. I'm not sure if that would work for #164 as it extends Scala by including support for static members.

[iam3yal]

Thanks Mr Obvious,

Have a nice day.

Edit: Just two tips that may or may not be so obvious to you:

1. Try to have some more respect toward people, people join discussions to have a discussion not to play "the size of your epeen" or similar game.

2. Try to lose that attitude and be less sarcastic.

[msfcolombo]

@eyalsk Thanks for the feedback. I try to show respect by carefully reading, understanding other people PoV, researching, answering in details and letting clear what I agree upon. I might have lost patience with a few demonstrations of lack of consideration for what I thought was very explicitly written. This impatience resulted in some hostility from my side, which I mistakenly took for nothing else than informal talk. But I never meant anything in detriment of anyone. So please accept my apologies.

[iam3yal]

@msfcolombo

I might have lost patience with a few demonstrations of lack of consideration for what I thought was very explicitly written.

It's not about that you failed to express your opinion or the concept behind the proposal but you need to understand that when you create an open/public discussion different people will have different opinions and may disagree with you, you should be open for good/negative feedback and the replies may not be the kind you expect and so by being defensive you only shoot yourself in the foot thus missing the opportunity to learn or otherwise, interact with people with different opinions.

Finally, if you want to end a discussion you can always state that you disagree or don't reply at all, personally I prefer the former approach but either is better over getting personal and aggressive, after all I think that we're all here to participate in the design of a language we love, contribute, learn, have fun and form a great community, at least that's why I'm here. :)

I'm not sure if you internalized the following idea: Sometimes people don't want to use the Factory pattern. There are cases where the Factory class is nothing more than a virtual method calling a constructor. The only reason to use a separate class is precisely the lack of metaclasses. Many factory classes are nothing more than manual implementation of a metaclass. This spec explicitly tells that without metaclasses, people are forced to use two classes, even if that is not required. Side note: among factory pattern and metaclasses, which concept do you think is older?

You state that the only reason we separate the factory class from the class it needs to create is done due to lack of metaclasses but there are more reasons to it, for example, breaking responsibilities.

Patterns emerge after a solution to a recurring problem is made and finally identified as such so I'd say metaclasses probably preceded the pattern.

My issue with this proposal is not strictly with factories but with the fact that any class is a potential factory and is offered through static calls, promoting this idea in my view, just in my own view doesn't lead to good design as far as implementation goes.

I honestly think that this proposal will require a lot more than just a change to the language such as the CLR and maybe the framework itself if reflection integration should be added so when you consider the benefit vs effort then in this case I think that the costs may outweigh the benefits but then I could be wrong.

I agree that the (overly exposed) simplification value might be low enough to left this out. But how about porting code from languages that support metaclasses? The capacity to accept migrations is an important value in any language.

Sure, but it really depends how far you want to go with this and who is your primary audience.

Repeating my previous comment, #164 allows a call to a static method through the generic type parameter. It became a polymorphic call without explicit use of reflection.

You're right you wouldn't have to use reflection because the generic type parameter is of a specific shape but you're wrong about the polymorphic call part, it would still be the same normal call to a static method.

[msfcolombo]

@eyalsk

I'm not being defensive, I just lack patience sometimes. I expect people to spend time studying and researching as I do, but that's not a good way to deal with a discussion. So thanks again, lesson learned.

You state that the only reason ...

The "only reason" is in the context of that paragraph, which tells "Sometimes ...", "There are cases...". Let me explain again in a more detailed way:

Sometimes the creation logic is too small to justify breaking responsibilities. In these scenarios, the only reason to split in two classes is to add polymorphysm, for which metaclasses would suffice.

Also, you are focusing too much on the Factory pattern, but that is only one of three scenarios where metaclasses can be useful. The two others are Singletons and Metadata (please see the spec).

you're wrong about the polymorphic call part, it would still be the same normal call to a static method

What is a polymorphic call for you? For me, is a call where the destination type is resolved at runtime (see here). It's not something limited to virtual method calls. Virtual method calls are subsets of polymorphic calls. There are even people telling that C++ templates are polymorphic despite being statically linked, though I don't think is appropriate.

A "normal static call" is a call where the type is known at compilation time. In this sense, #164 precludes that call to be "normal". The caller and callee might be at different assemblies, preventing the compiler to know each other. Stronger: The caller can make the call through an interface, making impossible for the callee to know the destination type before instantiation, which might even happen through reflection.

Setting jargon aside, the benefit of polymorphism is that a program will work with different types. So even if we disagree about what is a polymorphic call, we are talking about the same benefit, which should be enough to settle the proposition value.

EDIT: Rephrased to cover responsibility break.

[iam3yal]

@msfcolombo

I'm not being defensive, I just lack patience sometimes. I expect people to spend time studying and researching as I do, but that's not a good way to deal with a discussion. So thanks again, lesson learned.

The assumption that people don't spend the same time on the topic and research it as you do is one that you can't prove and more importantly puts you in a bad position because it makes you think that you know more thus closing yourself for further input.

There are plenty of people here from researchers to developers that not only read it but live it everyday.

Setting jargon aside, the benefit of polymorphism is that a program will work with different types. So even if we disagree about what is a polymorphic call, we are talking about the same benefit, which should be enough to settle the proposition value.

I disagree with some of your definitions, I think they are far from accurate but if #164 fits your needs then I guess there's nothing to discuss. 😉

[mbeutel]

@msfcolombo

// Delphi code:
type Foo = class(BaseClass)

   procedure SomeInstanceMethod( x: Integer );
   class procedure SomeStaticMethod( x: Integer );

end;	

The above is 100% equivalent to C#:

// C# code:
class Foo: BaseClass {

   void SomeInstanceMethod( int x) { ... }
   static void SomeClassMethod( int x ) { ... }
  
}

That's not quite correct. Delphi distinguishes between static and non-static class procedures. The former are much like static methods in C#, but the latter have an implicit Self argument which references the metaclass instance (as opposed to the class instance for instance methods). Let me illustrate with a more complete example:

interface

type
  TImage = class;
  TImageClass = class of TImage;
  TImage = class abstract
  public
    constructor CreateFromFile(AFileName: String);
    constructor CreateFromStream(AStream: TStream); virtual; abstract;

    class function MatchesFileSignature(AFileName: String): Boolean;
    class function MatchesStreamSignature(AStream: TStream): Boolean; virtual; abstract;

    procedure SaveToFile(AFileName: String);
    procedure SaveToStream(AStream: TStream); virtual; abstract;

    class procedure RegisterImageClass(AImageClass: TImageClass); static;
    class function SearchMatchingImageClassForFile(AFileName: String): TImageClass; static;
    class function SearchMatchingImageClassForStream(AStream: TStream): TImageClass; static;
  end;

implementation

constructor TImage.CreateFromFile(AFileName: String);
var
  Stream: TStream;
begin
  Stream := TFileStream.Create(AFileName, fmOpenRead);
  try
    CreateFromStream(Stream);
  finally
    Stream.Free;
  end;
end;

...

This could be replicated in C# as follows, with the metaclass made explicit:

    public abstract class Image
    {
        public abstract class Class
        {
            public Image CreateFromFile(string fileName)
            {
                using (var stream = new FileStream(fileName, FileMode.Open, FileAccess.Read))
                    return CreateFromStream(stream);
            }
            public abstract Image CreateFromStream(Stream stream);
            
            public bool MatchesFileSignature(string fileName) { /* ... */ }
            public abstract bool MatchesStreamSignature(Stream stream);
        }

        public static void RegisterImageClass(Class imageClass) { /* ... */ }
        public static Class SearchMatchingImageClassForFile(string fileName) { /* ... */ }
        public static Class SearchMatchingImageClassForStream(Stream stream) { /* ... */ }

        public void SaveToFile(string fileName) { /* ...*/ }
        public abstract void SaveToStream(Stream stream);
    }

Static class procedures are indeed equivalent to static methods in C#, but non-static class procedures are represented as instance methods of the metaclass; so are virtual and non-virtual constructors.

A subclass would look like this in Delphi:

type
  TBitmap = class(TImage)
  public
    constructor CreateFromStream(AStream: TStream); override;
    class function MatchesStreamSignature(AStream: TStream): Boolean; override;
    procedure SaveToStream(AStream: TStream); override;
  end;

And in C#:

    public class Bitmap : Image
    {
        private Bitmap(Stream stream) { /* ... */ }
    
        public new class Class : Image.Class
        {
            // assuming C# gets return type covariance
            public override Bitmap CreateFromStream(Stream stream) => new Bitmap(stream);

            public override bool MatchesStreamSignature(Stream stream) { /* ... */ }

            private Class() {}
            public static readonly Class Instance = new Class();
        }
        
        public override void SaveToStream(Stream stream) { /* ... */ }
    }

Type registration in Delphi:

  TImage.RegisterImageClass(TBitmap);

...in C#:

    Image.Class.RegisterImageClass(Bitmap.Class.Instance);

Usage in Delphi:

var
  ImageClass: TImageClass;
  Image: TImage;
begin
  ImageClass := TImage.SearchMatchingImageClassForFile('C:\test.bmp');
  Assert(ImageClass.MatchesFileSignature('C:\test.bmp'));
  Image := ImageClass.CreateFromFile('C:\test.bmp');

...in C#:

    var imageClass = Image.SearchMatchingImageClassForFile(@"C:\test.bmp");
    Assert.True(imageClass.MatchesFileSignature(@"C:\test.bmp"));
    var image = imageClass.CreateFromFile(@"C:\test.bmp");

[tannergooding]

Proposal that would add metaclasses to C++: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r0.pdf

[HallofFamer]

I like the general idea from the OP, but cant agree with the implementation. In Python for instance, everything is a first class citizen, so Animal and Class are actually objects themselves. With this in mind, the example code can be rewritten as below:

public abstract class Animal 
{
    public string Name { get; set; }

    public Animal(string name)
    { 
        Name = name;
    }

    public abstract string Cry();
}

public class Dog: Animal 
{
    public Dog(string name) : base(name){ }

    public override string Cry()
    { 
        return "Woof";
    }
}

var factory = Dog; //Dog itself is an object and can be assigned to a variable.
var myPet = new factory(); //Create a Dog Object. 
Console.WriteLn(myPet.Cry()); //Prints 'Woof';

You see, this updated implementation has no static methods, the implementation is vastly similar to the python example you can find from wikipedia. Unfortunately, it will not be possible in recent future since this requires C# to allow classes to be first class citizen like Python. By definition, metaclasses are classes of classes, so classes themselves are objects. Without classes as first class objects, it wont really be possible to implement true metaclasses, and you can only use static methods as inferior workaround.

So the point to take here is that, dont even worry about metaclasses until one day C# will have classes as first class citizen, which I aint sure when it will happen. We will see.

Reference: https://en.wikipedia.org/wiki/Abstract_factory_pattern#Python_example

[HaloFour]

@HallofFamer

IMO there are places where metaclasses might be a benefit but I think nearly all use cases are already solvable through other abstractions.

public abstract class Animal {
    protected Animal(string name) { }
    public abstract string Speak();
}

public class Dog : Animal {
    public Dog(string name) : base(name) { }
    public override string Speak() => "Woof";
}

Func<string, Animal> factory = name => new Dog(name);
var myPet = factory("Rover");
Console.WriteLine(myPet.Speak());

@tannergooding

As far as I can tell that C++ proposal is unrelated to this one. It'd be more closely related to source generators implemented via templates on steroids, C++ code generating C++ code to augment types at compile-time.

[HallofFamer]

@HaloFour

I agree that in many circumstances it is totally possible to replace metaclass by another technique, but anyway my response was just a direct message to the OP on the implementation details for metaclass as a feature. It assumes that if we are going to implement metaclasses, what the syntax we want it to look like, and what prerequisites are needed for it to work. I am not here to discuss the use cases for metaclasses, or whether we should implement metaclasses or not. If anything, I hope C# will consider first class types, so classes will become first class citizens just like objects. But it will be a different topic.

[msfcolombo]

The main benefit of metaclasses is that it removes verbosity, ambiguities and incorrectness of factory pattern implementations.

It's not a must-have language feature, but the benefit becomes clear when you replace lots of factory classes by metaclasses in your code base. Of course, this requires language support for metaclasses in first place.

It's like migrating from VSS or CVS to GIT: you have to actually use in order to feel the benefits. The difference is that GIT is there for anybody to try. Metaclasses are not there, at least in C#.

With such low external demand, I don't think this feature will be implemented in the short or mid term.

I have added this because there is at least one programming environment that makes heavy use of metaclasses with very clear benefits: Delphi Object Pascal and its visual control library.