stride3d
Review code annotations
Following #2155, we use other kind of annotations for instance for serialization.
Some annotations have the same name as ones existing in the .NET standard libraries (such as [DataContract]) which can at least be confusing and at most create mistakes where the wrong one is used.
The purpose of this issue is to list all annotations and review whether the standard ones can be used instead. If so, prepare a deprecation path where at first both can be used and later the custom one is removed.
On DataContractAttribute
Stride: alias == System: name
System: namespace isnt implemented in stride but it could be
System: IsReference doesnt exist in stride
System: IsInherited doesnt exist in system
DefaultDataMemberMode is only used 3 times and can be removed in obsoletion path
so the datatypes would be there for datacontract.. being generous isreference and isinherited can somehow be interpreted the same way but if you use system datacontract you have to use DataMember of system as well, so you dont clash
in DataMember you have
DataMemberMode = required , cant be removed
order = exists on both
name = exists on both
mask = used for excluding members based on the mask ( dont know exactly ), may be dropped? dont know
with C#13 i think a new feature comes to extend existing classes with properties, this may also be available for annotations, so just extend the datamember attribute of system by mask and datamember mode and it could work
[NotNull] can be yoinked, inconsistenly used accross the engine and is replacable by nullable
i think a new feature comes to extend existing classes with properties
If you're referring to extension types, this wouldn't help in our case:
Instance extension types cannot hold state. For example, they can’t include fields. They can access state on the underlying type or in another location. https://devblogs.microsoft.com/dotnet/dotnet-build-2024-announcements/
Let's say that's fine, I wonder how safe it is to just adopt it like so, would feeding strides' types to microsoft's DataContractSerializer even work out of the box ? What about the other way around, random libraries that have some of their types annotated with microsoft's DataContract, how would those be serialized through our serialization system ?
Renaming that attribute should be fairly painless though, just have to mark the current one as obsolete and users can just mass replace DataContract with whatever name we thought of for the new one.
goind towards incremental source generator inherited doesnt work anymore as each class needs the attribute as incremental source generators work on syntax not on semantic
we can still have the inherited bool to make a code fixer which is not relying on syntax that much as incremental source generator to automatically add the attribute which may be the better solution
sad that the new feature doesnt allow states :(
DataStyle(ScalarStyle) constructor can be removed
the scalar style of a string in yaml can be automatically handled by the serializer depending on the context so this is somewhat overcomplicating the thing
if you have multi line string => literal if you have spaces or special tokens/reserved words ( like !!null ) => go double quoted if you have a char with a special token => go single quoted if you have double line breaks => go for folded instead of literal.. which means folded and literal can be moved into 1 thing... even you can go so far to not support folded at all as literal is anyway doing the same
this way datastyle(DataStyle) is the only constructor that is needed => datastyle can be limited to classes only and properties can be removed, simplifies annotations by reducing its range of usage
by not auto handling this you receive bugs like with naming a scene #MainScene so the reference is written as 123545:#MainScene now its a comment , it should be written as "12345:#MainScene" so its also more error prone if the enduser has to handle it
the usage of the constructor in stride is afaic once... in a test...
after thinking about it datastyle konstruktor is also required for properties so... only the scalarstyle konstruktor can be removed