binaryprefs icon indicating copy to clipboard operation
binaryprefs copied to clipboard

Support for Lists, Sets and Arrays

Open Cilenco opened this issue 7 years ago • 4 comments

Are there any plans to add support for Lists, Set and / or arrays? Would be a nice additional feature for this library. Would you accept a pull request if I would implement this?

From a quick overview from the code I think only the Serializer and their SerializationStrategy needs to be reimplemented for this so it shouldn't be too hard.

Cilenco avatar Sep 03 '18 14:09 Cilenco

Hi ! What kind of generic types for collections do you mean? Because you just can't serialize all data types, only primitives and Strings. Of course, you can rewrite StringSetSerializer and Preferences classes for accepting all inheritors of Iterable interface but you should refactor serializer class for accepting all kinds of generics like primitives and Strings. All this steps requires mid codebase refactoring and if you desire create this functionality you should provide small reference proof-of-concept of your ideas.

--

Cheers, Alex

iamironz avatar Sep 04 '18 12:09 iamironz

I thought of collections of all primitive types, Strings and inheritors of Persistable.

To only rewrite the StringSetSerializer is not a good solution in my opinion. That would imply that each value is first converted to a string which may not be good practice. I think that rewriting all serializer classes is the better way to go here. I forked this repo and did some refactoring.

For POC look for example at the BooleanSerializer which now inherits from AbstractSerializer. There is most of the code for the Collection serialization. This new implementation does not break with the current one (except of FLAGS and NULL values) and also new test cases work pretty well.

Of course the Preferences as well as the PreferencesEditor interface have to change to accept collections and arrays but that shouldn't be the problem I guess.

Cilenco avatar Sep 04 '18 12:09 Cilenco

That would imply that each value is first converted to a string

nope, I meant that you should rewrite this one for working with generic types natively not String.valueOf

inherits from AbstractSerializer

This is not good enough because your base serializer has methods which is useless for most serializers and used not always, I prefer use delegates instead of inheritors, keep your code simple.

iamironz avatar Sep 05 '18 07:09 iamironz

Let me check if I got your point right:

Your idea is to only rewrite the StringSetSerializer (apart from Preferences) to accept all kinds of Collection. Then each Collection is serialized similar to a Set<String> and only the encoding of the types change? So e.g. List<Integer> would call a method in StringSetSerializer but the encoding of the elements itself is then handeled by IntegerSerializer?

Cilenco avatar Sep 05 '18 08:09 Cilenco