-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve overall type safety #18
Conversation
- Made no-args non-type-safe constructor private and added protected method instead to prevent accidential usage - Fixed being able to create EndTag lists (since they are not type-safe) - Fixed empty list and list.add().clear() not being equal due to typeID difference - Fixed clone() creating non-type-safe list if this list is empty
The last commit removes the typeID from ListTag and changes the TagFactory to work with this. |
- tag ids should only be in one place - correct wrong ListTag class java-doc - unchecked empty list toString() throws NPE
Behaviour now is that
Another thing i noticed which is not very important but i'd like to change is the way {
"type": "ListTag",
"value": {
"list": [
-128,
0,
127
],
"type": "ByteTag"
}
} |
See #14
ListTag
should remember its type when cleared.The current solution makes the no-args constructor of
ListTag
protected so deserialisation can still create an instance without knowing the type of theListTag
. Everything from outside creating a new instance ofListTag
will need to useListTag(Class<T extends Tag>)
.I also modified
ListTag#getTypeID()
andListTag#getTypeClass()
to match the old behaviour and be consistent with serialisation. Another reason for this is that these methods cannot be consistent with each other when theListTag
is empty.Example:
can only set the type class of the
ListTag
, but not the type id. Setting the type id occurs when adding the first element to the newListTag
.Therefore
ListTag#getTypeID()
will return0
andListTag#getTypeClass()
returnsEndTag.class
when theListTag
is empty.Other cases that will fail now but worked before:
The behaviour of
ListTag#asTypedList(Class<? extends Tag>)
also matches the new behaviour.All Unit Tests have been adjusted.