Skip to content
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 ImmutableMultimapSerializer. #61

Merged
merged 1 commit into from Oct 6, 2016
Merged

Improve ImmutableMultimapSerializer. #61

merged 1 commit into from Oct 6, 2016

Conversation

ghost
Copy link

@ghost ghost commented Oct 5, 2016

  • Add support for serializing ImmutableSetMultimap, which is missing.
  • Add explicit support for serializing ImmutableListMultimap
    (ImmutableMap delegates to ImmutableListMultimap in most cases, so it
    was implicitly supported).
  • Add tests for ImmutableSetMultimap & ImmutableListMultimap, and
    improve existing tests.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.1%) to 85.185% when pulling fb396ee on 3xp0n3nt:improve-immutable-multimap into f0659ca on magro:master.

2 similar comments
@coveralls
Copy link

Coverage Status

Coverage increased (+0.1%) to 85.185% when pulling fb396ee on 3xp0n3nt:improve-immutable-multimap into f0659ca on magro:master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.1%) to 85.185% when pulling fb396ee on 3xp0n3nt:improve-immutable-multimap into f0659ca on magro:master.

@magro
Copy link
Owner

magro commented Oct 5, 2016

Great, thanks for the PR! Do you think it makes sense to update the README related to this? Otherwise I'd be happy to merge as it is.

@ghost
Copy link
Author

ghost commented Oct 5, 2016

@magro No, I thought about it, but ImmutableMultiMapSerializer should have already been serializing ImmutableSetMultimap in the first place. Also, there are other Guava serializers that serialize specialized types in the same class, none of them mention that in the README. I feel that the design of the README would need to change to accommodate such details, by allowing a paragraph or so for each serializer class, explaining exactly what is and isn't supported, gotchas, etc. Improving the granularity of the README is a mini project in itself, and should be a separate issue, in my opinion. As it is, there is only a small, vague, blurb for each class, so this additional information would be out of place on its own.

@coveralls
Copy link

coveralls commented Oct 5, 2016

Coverage Status

Coverage increased (+0.1%) to 85.185% when pulling e096e26 on 3xp0n3nt:improve-immutable-multimap into c29d105 on magro:master.

@ghost
Copy link
Author

ghost commented Oct 5, 2016

@magro Another idea I considered would have been to create a separate serializer class for ImmutableSetMultimap, which would eliminate the type checking, but I guess it just didn't feel like the right approach. Think about it like this: ImmutableMultimap already delegates by default internally to ImmtuableListMultimap. Do we pretend not to know this and create a separate serializer for ImmutableListMultimap as well? This could create confusion, if people don't know the internal workings of ImmutableMultimap, they would want to know why there is a separate ImmutableSetMultimapSerializer, but no ImmutableListMultimapSerializer. We could create both, but then again, other serializers don't split these up, so it would be deviating from the overall library design, and it would make ImmutableMultimapSerializer redundant, as ImmutableMultimap already delegates to ImmutableListMultimap.

The reason for the type checking is due to a design quirk in ImmutableMultimap. The nested Builder class will always create an ImmutableListMultimap when calling ImmutableMultimap#builder, so even if you are deserializing an explicit ImmutableListMultimap subtype, it will just work to call ImmtuableMultimap#builder (no requirement to call ImmutableListMultimap#builder - which is how it currently works without this PR), but if you are serializing an ImmtuableSetMultimap, you MUST call ImmutableSetMultimap#builder, which requires checking the type when deserializing to get the correct builder.

Personally, for my use case, I don't want to worry about what concrete implementation might be used by another developer in another module. For example, I register ImmutableMultimapSerializer in a common module, shared by client & server modules, communicating via KryoNet. I don't want to worry if the server developer is going to use an ImmutableSetMultimap, ImmutableListMultimap, or any other subtype. I would prefer one registration for the base type, and expect it to cover all the concrete implementations. Also, I don't want serializer registration explosion - having to register one class per subtype. So I think the library succeeds for the most part in this design, except in cases like this where the support for ImmutableSetMultimap should have been there originally, but wasn't, leading to a breakage later when another developer on my project decided to use an ImmutableSetMultimap in a network-serializable class.

I would prefer stricter acceptance guidelines when new serializers are being PR'd - making sure all subtypes are accounted for explicitly with testing. (Of course, there will be exceptions, but those should _known_ and then noted accordingly in the README.)

@ghost
Copy link
Author

ghost commented Oct 5, 2016

After writing my thesis up there, I realized that when a serializer class deals with subtypes in the same class, it is usually internal subtypes - at least for Guava - that are not exposed via a public API, so it's not really an issue in those cases. However, for API types, there are actually separate serializers, e.g. for ImmutableList & ImmutableSet, LinkedHashMultimapSerializer & LinkedListMultimapSerializer, etc. So maybe there is some precedent for creating a separate serializer for ImmutableSetMultimap.

@magro Let me know how you'd like to proceed. I have no problem adjusting the PR if you want to go that route.

- Add support for serializing ImmutableSetMultimap, which is missing.

- Add explicit support for serializing ImmutableListMultimap
  (ImmutableMap delegates to ImmutableListMultimap in most cases, so it
  was implicitly supported).

- Add tests for ImmutableSetMultimap & ImmutableListMultimap, and
  improve existing tests.
@coveralls
Copy link

coveralls commented Oct 5, 2016

Coverage Status

Coverage increased (+0.1%) to 85.185% when pulling eeb8393 on 3xp0n3nt:improve-immutable-multimap into c29d105 on magro:master.

@magro
Copy link
Owner

magro commented Oct 6, 2016

Thanks for the explanation, all makes sense!

Regarding PR acceptance guidelines: I can completely understand this! Unfortunately I can only do basic checking but don't have the time to look into it / do reviews as I'd do them during my day job (other OSS projects and "life" need some time as well). The alternative for me would be to significantly slow down PR acceptance or don't do anything on it at all. Therefore I'm following the "better done than perfect" attitude here, hoping that OSS will still lead to a better quality in the long term. In that sense, thanks a lot for your current contributions! :-) I'd also be happy to have more people help maintaining kryo and kryo-serializers... :-)

Back to the code: I don't have a clear preference which way to go, therefore I'd merge it as it is. Ok?

@ghost
Copy link
Author

ghost commented Oct 6, 2016

@magro Yeah, I understand. I'm fine with merging as-is! And you're very welcome!

@magro magro merged commit a2d16aa into magro:master Oct 6, 2016
@ghost ghost deleted the improve-immutable-multimap branch October 6, 2016 06:37
@magro
Copy link
Owner

magro commented Oct 6, 2016

Thanks!

@ghost
Copy link
Author

ghost commented Oct 6, 2016

@magro No problem! Could I get a release for this?

@magro
Copy link
Owner

magro commented Oct 6, 2016

Of course, until tomorrow, today on travels.

@ghost
Copy link
Author

ghost commented Oct 6, 2016

@magro Sure, thanks a lot!

@magro
Copy link
Owner

magro commented Oct 6, 2016

kryo-serialzers 0.41 is just on its way to maven central.

@ghost
Copy link
Author

ghost commented Oct 7, 2016

@magro Thanks again!

@ghost
Copy link
Author

ghost commented Oct 7, 2016

@magro Hmm, the latest version in Maven Central is 0.38 - shouldn't 0.39 and 0.40 have already been there, at least? I don't know how long it takes, but I wouldn't think more than a few hours.

@ghost
Copy link
Author

ghost commented Oct 7, 2016

@magro
Copy link
Owner

magro commented Oct 7, 2016

Yeah, mvnrepository always takes some time to catch up, the repo itself is the truth :-)

@magro
Copy link
Owner

magro commented Oct 7, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants