The verse programming language has many interesting restriction messages that are very much ambiguous from the developer’s perspective.
Here’s a non-exhaustive list of such messages:
-
The definition of %s is not marked with the <final_super> attribute, but the published definition is. For backward compatibility, the new version must be <final_super>.
-
The definition of class %s is marked , but the published definition is neither nor . For backward compatibility, the new version cannot be .
-
The definition of class %s is not marked , but the published definition is. For backward compatibility, the new version must be .
-
The type of this definition (%s) is not compatible with the type of the published definition (%s).
-
The value of this closed world definition (%s) is incompatible with the value of the published definition (%s).
-
This definition doesn’t have a default value, but the published definition does. Removing the default value of an instance member is a compatibility breaking change.
-
This definition is a class, but the published definition is a struct. Classes are not backward compatible with structs.
-
This definition is a concrete class, and the published definition is a non-concrete non-final class. Concrete classes are not backward compatible with non-concrete classes unless they are final.
-
This definition is a final class, but the published definition is a non-final class. Final classes are not backward compatible with non-final classes.
-
This definition is a non-concrete class, but the published definition is a concrete class. Non-concrete classes are not backward compatible with concrete classes.
-
This definition is a non-unique class, but the published definition is a unique class. Non-unique classes are not backward compatible with unique classes.
-
This definition is a struct, but the published definition is a %s class with %s. Structs are only backward compatible with final classes with no inheritance.
-
This definition is an abstract class, but the published definition is a non-abstract class. Abstract classes are not backward compatible with non-abstract classes.
-
This definition of %s is a castable interface, and the published definition is a non-castable. Castable interfaces are not backward compatible with non-castable interfaces.
-
This definition of %s is a non-castable interface, but the published definition is a castable interface. Non-castable Interfaces are not backward compatible with castable interfaces.
-
This field is final, but the published field is non-final. Changing a non-final field to be final is not backward compatible.
-
This function is a %s function, but its published definition is a %s function. Changing between constructor and non-constructor function is a compatibility breaking change.
-
Reordering enumerator values of published enumeration %s is not backwards compatible.
-
%s was already published as a enumeration. Republishing it as an enumeration is not backward compatible.
Please explain what “publishing” means and in which context. Publishing is very much ambiguous with the <public> access modifier.
Aside from persistable effect where the backwards compatibility is strictly required to not loose player data, why do the above restrictions exists?
Why can’t we create an internal class in version 1 of our game and not mark it as castable for example. In version 2 of our game we decide that we would like to support casting for this particular type. According to the above messages, this might not be possible anymore.
Why is that? A new set of binaries will be supplied for version 2 anyways and the type is internal and not publicly accessible except the own project. Why can’t this type be updated in whatever manner the author of the project sees fit?