You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
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.
The text was updated successfully, but these errors were encountered:
As libxml cannot be imported to Swift directly, ResponseDetective currently uses
RDTBodyDeserializer
,RDTXMLBodyDeserializer
andRDTHTMLBodyDeserializer
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:
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.
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.
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:
.m
file that uses libxml and contains implementation of XML and HTML pretty-printing,.h
file that contains interface of above implementation,.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.The text was updated successfully, but these errors were encountered: