How to create custom ValueObjectAttribute attributes with my own defaults and custom properties?

[prlcutting]

Sadly, it seems that this used to be possible, but not now, according to the documentation:

But I find myself with exactly this need. I attempted to create a custom ValueObjectAttribute-derived attribute class and pass down to the base class my preferred configuration defaults. But Vogen didn't honor it. That seems consistent with the early part of the documentation (which I only discovered after the fact), however, the last part of the documentation seems to suggest doing exactly what I did. I'm a bit confused. Also, how does "using the type alias feature" help here? If anybody could enlighten me on this, it would be much appreciated!

I have resorted to creating my own non-ValueObjectAttribute-derived marker attribute (along with some new, custom properties) and source generating another portion of the partial struct alongside what Vogen source generates. In other words, my VOs have two attributes applied to them: the Vogen one, and my custom one. But this is far from smooth. The DX isn't as nice (two attributes to achieve one goal rather than one). A separate issue perhaps, but things like overriding ToString etc. don't work, as Vogen is blissfully unaware of my own source generation, and as such, two duplicate ToString implementations get source generated, which of course results in a compilation error. I have dozens of VOs that I would like to create with the same custom ToString implementation, and repeating it on each one to prevent Vogen from generating its default implementation seems unfortunate. An option to disable a ToString generation might be a helpful workaround. BTW... I'm creating struct-based VOs, so a base class isn't an option.

[SteveDunn]

Hi, thanks for the feedback. It's unfortunate that this isn't possible as it'd be invaluable!
The documentation needs updating to remove this ambiguity, plus, I honestly can't remember why I added the link to the type alias feature!

My time is quite limited so it's unlikely I can spend the time necessary for this to be fixed in a way that doesn't impact performance of the source generator.

[prlcutting]

Hi Steve. Thanks for the reply to my questions and clarifying a few things for me.

Do you recall, was the source-generation performance issue related to needing to discover all attributes, and then checking if any of them derive from ValueObjectAttribute? I imagine that there might be a little bit of a reflection hit there, but wonder if as each attribute type is encountered for the first time it could be cached in a HashSet<Attribute> of matching and unmatching attributes. That would incur a modest memory increase, but make subsequent encounters of the same attribute much faster. I'm speculating here as to where the performance concerns originated from, so could be off, and you probably already considered this.