Closed jonthegeek closed 2 months ago
I think MAYBE I'm supposed to manually validate in the setter in cases where I want to validate. That causes an issue during initialization, but I was able to work around it. Long-term, that feels likely to cause confusion, and I'm still not sure whether it's intentional.
Hmmmm, not if this is a bug or not, but if it isn't we should document that you need to call validate()
yourself if you're providing a custom setter.
It's a pain during initialization, because things "after" this property aren't set yet (so validation of the overall thing definitely can fail). I worked around it by setting an "initialized" attribute if it didn't exist (and not validating), or validating if the initialized attribute is there. Definitely hacky right now but it gets the job done.
I think this will be fixed once https://github.com/RConsortium/S7/pull/396 is merged. The current prop<-
method does not run validate(object)
after running a custom setter, but it should.
This is fixed on main now. Thanks for reporting!
My mental model is that properties are responsible for validating themselves (for the most part), but the class validator can check to make sure that the properties work with one another. However, a property with a setter breaks that model.
Created on 2023-12-05 with reprex v2.0.2
Is this working as intended? Is there a way to trigger overall validation after a property that has a setter is updated?