tqchen edited a comment on pull request #9861: URL: https://github.com/apache/tvm/pull/9861#issuecomment-1007093752
Thanks lily. Let us analyze the overall pros and cons of the set of approaches. The advantage of introducing such implicit behavior is of course when a field default to null and having such implicit behavior of the loader(that defaults to null) will automatically loads the staled version. On the other hand, introducing implicit behavior can also bring other consequences. For example, let us assume that a community members want to introduce a new field, but the default value of the filed is not a null value(say incomplete type, or some value derived by other existing fields). Having a default loading behavior would then mean that the load still happens "successfully", but then later we get a segmentation fault because null was not a valid solution. Similarly, in another real updates that happened before, imagine we want to rename a field from "name" to "myname". The implicit behavior was expecting an optional "myname", but the serialized field is name, and the implicit behavior simply set "myname" to null. This will again leads to a segfault some at some later time pt. In both cases, an explicit error message indicating the incompletion of the serialized field will make a more clear error message and prevent can possible future failures that are harder to debug. Of course the price is that we get more explicit error messages and needs to deal with them. The particular case of backward compatibility can be resolved by having an explicit upgrader, which could contain a few more lines of python code with a clear intention to the particular object type of interest. The alternative have smaller impact surface when comparing to the implicit behavior and will not cause unintentional extra behaviors as examples listed above. Because of the explicit customization, the upgrader can be customized in a way that also handles the above examples that implicit behavior may not handle correctly. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
