Move away from Guid identifier for RulesFor

[einari]

• [ ] Remove the Identifier and use the types full name (namespace + type name) as default.
• [ ] Introduce a new [RuleSet] that takes one argument; an override of the name. This attribute should be optional and only used for overriding the name.
• [ ] Make the Identifier on the existing RuleAttribute virtual and RuleId a concept of string. The default implementation would be to use the types fullname (namespace + type name). This would also mean we don't need the RuleAttribute class to be an abstract class.

[woksin]

@einari Shouldn't the task simply be to change RuleId to be a concept of string and change the RuleAttribute instead of introducing a new Rules attribute?

[woksin]

Ohh, I think I see now why we need the Rules attribute for the RulesFor type

[einari]

Yeah.. This is actually something I had forgotten about. Its two different use-cases. It doesn't make sense to have two attributes with the same name.

For the existing RuleAttribute we just want to make the Identifier property optional. Default behavior should then be that its identifier is the types fullname (namespace + type name).

The other use case is for a RuleSet, I suggest we call the attribute for this issue RuleSetAttribute.

[woksin]

There a bit mix here in how it's used, for instance RulesFor is for a type, while RuleAttribute is for a property or parameter, thus the strategy of getting the identifier from the type name does not really work? Also the IRule interface with the Identifier probably won't really work with all of these scenarios, so I think there has to be some more thinking behind this. This was a bit more challenging than I anticipated... 😆