Support private and protected Custom Properties #150
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It is common and good practice to make properties and fields private or protected, so that the code flow becomes more obvious (fewer ways to change the state of a class instance) and less error prone.
For that reason codebases that protected most properties from other classes and utilize SuperTiled2Unity cannot use Custom Properties unless applying this patch.
On the patch correctness:
The reasoning to only write to public fields might have been to be consistent with the access modifier.
The counterargument to that would be that Unity well supports serialization and deserialization of private and protected fields, by using the
[SerializeField]
attribute. And the tiled 2 unity import process resembles deserialization.If it is deemed important to distinguish public and non-public property Custom Properties, then one might add another checkbox in the Import user interface (similar to the
Tiles As Objects
checkbox).