Code generator for abstract classes derived from Entity<TId, TIdPrimitive>

[ebarkalov]

Hi @Timovzl

I use a base class for my entities to contain some common properties, inheriting from Entity<TId, TIdPrimitive>. Unfortunately, when doing so, custom ID type does not get generated. Would this be possible in future to extend code generation functionality, so it generates custom ID types for entities that inherit from Entity<TId, TIdPrimitive> through the other base class?

Thank you!

Eugene

[Timovzl]

Hi Eugene,

I understand your requirement of a custom base type for common concerns. I think it would be useful to support that scenario.

It's a tricky one to implement efficiently in the incremental source generator. The first step of the generator, IdentityGenerator.FilterSyntaxNode(), aims to exclude as many false positives as possible. Besides identity types with the [SourceGenerated] attribute (not relevant here), it looks at anything that has the words "Entity<[AnyType], [AnyType]>" in its list of inherited/implemented types. At this point, there is no knowledge of that type, except for its name and arity (type parameter count).

As you can tell, the above is quite efficient. The next method in the chain, IdentityGenerator.TransformSyntaxNode(), takes all candidates selected by the filter method and inspects the (now interpreted) syntax trees. For example, in the unlikely case where it turns out that you had used your own Entity<T1, T2> base type, i.e. one from a different namespace, then we have received a false positive from the filter and return null to ignore it.

The transformation method is the one that could dig through actual inheritance chains to find if the base type is in there. The filter method, however, knows only type names, and does not know what these types might inherit from.

Since the transformation method would need to do the more thorough detection, the syntax method would need to allow more types to pass through. I'm considering what it could still filter on, to avoid a multitude of false positives.

• For inheritance from Entity<TId, TIdPrimitive>, there is no [SourceGenerated] attribute, since it is the ID type that is being source generated, not the entity itself. We can't filter on the presence of an attribute.
• We can continue to filter on concrete, non-generic classes, but most types fit that description.
• We can continue to require that something is inherited/implemented, but that is not much more selective.
• We could require that something is directly inherited/implemented that contains the word "Entity" in its name. This would significantly filter the candidates. Even if you wanted to name your abstract base ThingyRelatedToOrders, you could add your own IEntity interface and implement that directly from each concrete entity type to enforce source generation.

I'd love to hear your thoughts on this approach, as well as any alternatives you can come up with.

[Timovzl]

Now considering an alternative design.

A generic variant of the [SourceGenerated] attribute, [SourceGenerated<T>]. This could enable a certain level of reuse in the future.

When an entity has the [SourceGenerated<ItsOwnIdType>] attribute, the ID type will be generated even if the entity only indirectly inherits from Entity<TId, TIdPrimitive>. The inheritance is still necessary, for the generator to know TIdPrimitive.

This would allow the following to work:

[SourceGenerated<BananaId>]
public class Banana : Fruit<BananaId>
{
}

public abstract class Fruit<TId> : Entity<TId, ulong>
{
}

@ebarkalov I welcome your feedback.

[ebarkalov]

Hi @Timovzl

Thank you so much for sharing your thoughts and ideas! Apologies for not commenting your first reply - honestly I've never had to do any code generation stuff, so not familiar with all the intricacies.

I think your idea with generic attributes is brilliant!

In any case, the issue that I raised is not critical, because identity value object can be generated separately:

[SourceGenerated]
public partial struct BananaId : IIdentity<ulong>
{
}

Thank you again for supporting such a great library - I use it for my domain model and enjoy it very much!

[Timovzl]

Thanks @ebarkalov. You make a very good point about the workaround.

In fact, let's make the change, considering how clean and natural the workaround is, and how confusing the generic SourceGenerated attribute might be (when you're looking for the non-generic one and are scratching your head about the generic one that also appears).

Instead, version 2.1.0 will allow a record struct to be used for source-generated identities, thus optionally reducing the workaround's number of lines from 4 to 2, by not requiring any curly braces:

[SourceGenerated]
public readonly partial record struct BananaId : IIdentity<ulong>;

(The number of keywords on type declarations in C# is starting to boggle the mind.)