Do we still need to register validators?

[CalebCourier]

Currently, all validators, both from the hub and local custom validators, must be registered using the register_validator decorator. This decorator does a few things:

1. It conforms all decorated entities into a Validator subclass (classes and functions alike).
2. It verifies the datatypes specified in the decorator are valid.
3. It caches the validator's class against the name it is registered against for future lookups.

Of these three actions:

1. This is the only useful side effect, and the decorator could be kept around specifically for this use case if we still want to support functions as validators
2. This is obsolete. We no longer reference or enforce the datatypes a validator is registered against. Even if we do want to start enforcing this, there are better ways to collect this information, e.g. required arguments when calling super init so we can reference an enum.
3. This is only used when re-hydrating validators from a serialized form i.e. rail or json. This also only indicates that we need to retain the registry, it does not directly necessitate the current registration method. If we wanted registration to be more "magic", we could auto-populate the registry using something like Validator.__subclasses__().

If we were to remove the current requirement of decorating validators with register_validator, I foresee the following Pros and Cons. Please add other Pros and Cons you see in the comments.

Pros:

• Simplified user experience - The user now only has to subclass Validate in order to create a usable Validator
• Opportunity to simplify/conform validator creation - That is, I'm in support of dropping support for functions as validators. This method of validator creation seems like an anti-pattern and the user can turn the same code into a class-based validator by adding one short line of code: class MyValidator(Validator): and then make their existing function the validate method.
• Remove some baggage from the codebase

Cons:

• Technically removing a feature if we drop support for functions as validators
• Registry now relies on python magic from the import chain rather than an explicit assignment
• Subclasses of existing validators will have to be recursively discovered

Caveats:

• We still need distinct validator ids to continue to support rail and json serialization. These will still need to be associated with the validator somehow

[zsimjee]

Opportunity to simplify/conform validator creation - That is, I'm in support of dropping support for functions as validators. This method of validator creation seems like an anti-pattern and the user can turn the same code into a class-based validator by adding one short line of code: class MyValidator(Validator): and then make their existing function the validate method.

This is the most convincing thing here. I think it's a risk in itself - validator functions are the easiest way to write validators, but you're correct in that they're an antipattern and not super easy to roll up.

Registry now relies on python magic from the import chain rather than an explicit assignment

This is a little concerning as we think of branching to different languages. Since we're keeping an ID, I guess this adds to the list of impls we need to make case-by-case for each language?

We still need distinct validator ids to continue to support rail and json serialization. These will still need to be associated with the validator somehow

ID should def not be dropped from the JSON schema def of a Validator.

I like this train of thought. Now that we've moved totally to hub, I also think we can update how we think about validator references in RAIL.

[CalebCourier]

This is a little concerning as we think of branching to different languages. Since we're keeping an ID, I guess this adds to the list of impls we need to make case-by-case for each language?

Agreed, I think this is my biggest hang up for deprecating/removing the decorator. Namely because decorators are one of the few things in common across our target languages (Python, JS, anything JVM) that are meant for performing tasks like this.