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

Hide Objective-C nature of XML and HTML body deserializers #42

Open
akashivskyy opened this issue Aug 18, 2017 · 1 comment
Open

Hide Objective-C nature of XML and HTML body deserializers #42

akashivskyy opened this issue Aug 18, 2017 · 1 comment

Comments

@akashivskyy
Copy link
Collaborator

As libxml cannot be imported to Swift directly, ResponseDetective currently uses RDTBodyDeserializer, RDTXMLBodyDeserializer and RDTHTMLBodyDeserializer types, thus making its unwanted Objective-C nature public.

Ideally, I'd like to remove all traces of Objective-C files from the project. This could be achieved in a couple of ways:

  1. Use an Objective-C libxml wrapper as an external framework and import it directly in Swift. This is the worst solution because it adds an unwanted third-party dependency to ResponseDetective.

  2. Create a project-private libxml wrapper as a separate framework and import it directly in Swift. This is better than the 1st solution, but adds a lot of unwanted complexity, especially with header search paths, linking and module maps.

  3. Use a project-private module (not to be mistaken with framework) that exposes needed libxml functionalities internally to ResponseDetective, but no further. This is the best solution.

Assuming the 3rd solution is chosen, the proposed implementation would consist of the following files:

  • A .m file that uses libxml and contains implementation of XML and HTML pretty-printing,
  • A non-public .h file that contains interface of above implementation,
  • A .modulemap file that defines a module including the above header.

As a result, ResponseDetective could import XMLPrettyPrinting (exemplary name of module) directly and use refined-for-Swift APIs without them leaking to the outside world.

@akashivskyy akashivskyy added this to the 2.0 milestone Aug 18, 2017
@akashivskyy
Copy link
Collaborator Author

Well, it looks like Xcode 9.3 fixed this for us – libxml2 is now a module, which means we can do straight import libxml2 in Swift. 🎉

@akashivskyy akashivskyy removed this from the 2.0 milestone Mar 26, 2020
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

No branches or pull requests

1 participant