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

Finalize exported serialization package #66

Open
sagikazarmark opened this issue Sep 6, 2016 · 7 comments
Open

Finalize exported serialization package #66

sagikazarmark opened this issue Sep 6, 2016 · 7 comments

Comments

@sagikazarmark
Copy link
Contributor

I would like to finalize this package soon:

https://github.com/fxmlrpc/serialization

What do you think about integrating it into this library afterwards? (extend/composition)

@sagikazarmark
Copy link
Contributor Author

Ping @lstrojny

@lstrojny
Copy link
Owner

@sagikazarmark In general I believe that’s a good idea. What I disagree with is the B/C breaks it would bring in it’s current state. The breaks would mostly be changes in interface naming and the namespace. I don’t think those are necessary and would make life just harder for the users of this package, especially since we had quite a bit of breaking changes in the past already, so I want to give them some rest. A smaller issue are the whitespace changes that from my point of view make readability worse.

@sagikazarmark
Copy link
Contributor Author

Sorry, I probably wasn't clear: I would like to integrate it in a non-BC breaking way if that's possible. Now that I kind of finalized the extracted codebase, it would probably be better to avoid maintaining the same code in two different libraries.

@sagikazarmark
Copy link
Contributor Author

So probably the best way would be to have some kind of composition of the new serializers in the "old" ones.

@lstrojny
Copy link
Owner

lstrojny commented Feb 1, 2017

@sagikazarmark yep, that sounds good. I don't want to break B/C for the client at all right now. But including the serializers as an external package instead, sure.

@sagikazarmark
Copy link
Contributor Author

sagikazarmark commented Jun 20, 2017

Okay, I will try to pick up this one.

BTW Are you still committed to the separation work we started a few years ago @lstrojny? Because if you are and I can find the time I will try to move things forward a little bit.

@lstrojny
Copy link
Owner

@sagikazarmark happy to continue the separation although I don’t expect to have too much time to spend on it.

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 a pull request may close this issue.

2 participants