Is C# 9 record POCO?

Question

I use IL Spy to decompiler record code, e.g:

public record Record1(string Name);

decompiler in IL Spy

using System;
using System.Collections.Generic;
using System.Runtime.CompilerServices;
using System.Text;

public class Record1 : IEquatable<Record1>
{
    protected virtual Type EqualityContract
    {
        [System.Runtime.CompilerServices.NullableContext(1)]
        [CompilerGenerated]
        get
        {
            return typeof(Record1);
        }
    }

    public string Name
    {
        get;
        init;
    }

    public Record1(string Name)
    {
        this.Name = Name;
        base..ctor();
    }

    public override string ToString()
    {
        StringBuilder stringBuilder = new StringBuilder();
        stringBuilder.Append("Record1");
        stringBuilder.Append(" { ");
        if (PrintMembers(stringBuilder))
        {
            stringBuilder.Append(" ");
        }
        stringBuilder.Append("}");
        return stringBuilder.ToString();
    }

    protected virtual bool PrintMembers(StringBuilder builder)
    {
        builder.Append("Name");
        builder.Append(" = ");
        builder.Append((object?)Name);
        return true;
    }

    [System.Runtime.CompilerServices.NullableContext(2)]
    public static bool operator !=(Record1? r1, Record1? r2)
    {
        return !(r1 == r2);
    }

    [System.Runtime.CompilerServices.NullableContext(2)]
    public static bool operator ==(Record1? r1, Record1? r2)
    {
        return (object)r1 == r2 || (r1?.Equals(r2) ?? false);
    }

    public override int GetHashCode()
    {
        return EqualityComparer<Type>.Default.GetHashCode(EqualityContract) * -1521134295 + EqualityComparer<string>.Default.GetHashCode(Name);
    }

    public override bool Equals(object? obj)
    {
        return Equals(obj as Record1);
    }

    public virtual bool Equals(Record1? other)
    {
        return (object)other != null && EqualityContract == other!.EqualityContract && EqualityComparer<string>.Default.Equals(Name, other!.Name);
    }

    public virtual Record1 <Clone>$()
    {
        return new Record1(this);
    }

    protected Record1(Record1 original)
    {
        Name = original.Name;
    }

    public void Deconstruct(out string Name)
    {
        Name = this.Name;
    }
}

I read class - 'POCO' definition and think it's true, but it's not like below kind simple property POCO.

public class Record1
{
    public string Name {get;set;}
}

Because it contains behavior like

• immutable by {get;init;}
• value equals by override Equals

    public virtual bool Equals(Record1? other)
    {
        return (object)other != null && EqualityContract == other!.EqualityContract && EqualityComparer<string>.Default.Equals(Name, other!.Name);
    }

But I'm not sure for it.

Answer 1

The problem here is POCO is actually not a technical term, it's more a colloquial term to describe a loose set of behaviors/properties which has its origins in other languages and at best context dependent.

Furthermore, there are actually no reference to the word POCO (or in its expanded form) in the .Net or C# specifications. So all we can do is use such language loosely based on its colloquial meaning. Which is an object that has no dependencies on external frameworks.

When you compile a Record it creates a fairly pedestrian class which implements a BCL interface.

Is this enough for it to be now classed as a complex object (because it has a contract to a BCL interface)? Well I guess it depends on who you ask.

And if the answer is yes, where do we draw the line? Are classes with async methods that have dependencies on a compiler generated IAsynStateMachine implementation, or closures, or the many other instances where the compiler generates dependencies POCO?

In short, the term POCO has no real use. It only has if the people who are discussing the concept can agree on a narrow well-defined definition.

So if someone asks you if something is POCO, you should ask them back "stringently define POCO for me".