Ok, after trying to get this building on Linux, I have discovered what you mean. I have gotten it building successfully on Linux, unfortunately this required changes to build settings in other modules, because /usr/include/libxml2 wasn’t being added to the search locations. And this then results in needing to add “-I/usr/include/libxml2” to the command line any time you want to build anything using Foundation! (including just typing “import Foundation” in the REPL, heh). Which is obviously less than ideal. There is already an implementation for all this stuff in CoreFoundation, but it’s marked as being deprecated as of OS X 10.6, with a note to use NSXMLDocument (or libxml2) instead! Not exactly a helpful recommendation when you’re implementing NSXMLDocument heh. Should I just add wrappers in CFXMLInterface for the libxml2 functions I need? That might be the easiest way to just get everything building with minimal changes to other modules.
Thanks, Robert Thompson Software Engineer WillowTree, Inc.® willowtreeapps.com <http://willowtreeapps.com/> > On Dec 18, 2015, at 8:05 PM, Philippe Hausler <phaus...@apple.com> wrote: > > Dealing with the cross platform part of the module map portion may be a bit > tricky; I had to use some of libxml2 for CFXMLInterface it is effectively a > simple wrapper around a few xml c calls that are a bit swift-friendlier. > Perhaps that might make some of that integration easier. However if you do > find a decent way of dealing with the module map differentials between linux > and mac os x I would be interested to see if we could improve the state of > affairs in that bridged portion. > >> On Dec 18, 2015, at 2:33 PM, Robert Stephen Thompson via swift-corelibs-dev >> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote: >> >> Ok, sounds good to me. I have quite a bit done at this point, but it’s not >> “pretty enough” for a real PR yet. If people really want to look at the >> ugliness, >> https://github.com/rothomp3/swift-corelibs-foundation/tree/feature/NSXMLDocument >> >> <https://github.com/rothomp3/swift-corelibs-foundation/tree/feature/NSXMLDocument> >> is where it lives. >> >> Thanks, >> Robert >>> On Dec 18, 2015, at 1:58 PM, Tony Parker <anthony.par...@apple.com >>> <mailto:anthony.par...@apple.com>> wrote: >>> >>> Hi Robert, >>> >>> There actually already is some discussion on the swift-evolution list about >>> a language feature to enable factory methods, which would help us to >>> implement these kinds of things. It is a common pattern in Foundation to >>> return subclasses from initializers (NSNull, NSPredicate are in the same >>> boat, among many others), so I’m hoping we can get that one moving along >>> soon. If you can find that thread, go ahead and reply to it with additional >>> justification if you want. >>> >>> I think we should try to move forward on this as if we’ll eventually get >>> that feature. It’s pretty clear that we need it. We may need to work on >>> other parts of the implementation first until we get it. >>> >>> - Tony >>> >>>> On Dec 18, 2015, at 9:21 AM, Robert Stephen Thompson via >>>> swift-corelibs-dev <swift-corelibs-dev@swift.org >>>> <mailto:swift-corelibs-dev@swift.org>> wrote: >>>> >>>> Since I recently did a small implementation of NSXMLNode and NSXMLDocument >>>> to use in an iOS project, I decided to tackle doing the full-featured one >>>> here. It’s not that hard, doing it as a wrapper on libxml2, except I’ve >>>> run into a bit of a snag with making the semantics exactly match Darwin >>>> Foundation: you can’t return a subclass from init! This really only >>>> matters in one place, but it matters quite a bit there. The de facto >>>> designated initializer for NSXMLNode is init(kind: NSXMLNodeKind, options: >>>> Int). In pure Swift, this always returns an NSXMLNode, not the appropriate >>>> subclass! Which, of course, means as? returns nil, as! (and >>>> unsafeDowncast) crash, etc, when you end up trying to retrieve one and >>>> treat it as the subclass it’s “supposed” to be. I’m completely stumped as >>>> to any way around this. It might be that it’s just impossible to match >>>> Darwin Foundation semantics without a new language feature for this, which >>>> obviously would have to go through swift-evolution and then actually be >>>> implemented. Am I correct, or is there something I’m missing? Also, should >>>> I go ahead and implement the rest of this without the exactly matching >>>> semantics because something is better than nothing? >>>> >>>> Thanks, >>>> Robert Thompson >>>> Software Engineer >>>> WillowTree, Inc.® >>>> willowtreeapps.com <http://willowtreeapps.com/> >>>> <PastedGraphic-1.png> >>>> >>>> _______________________________________________ >>>> swift-corelibs-dev mailing list >>>> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev >>>> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev> >>> >> >> _______________________________________________ >> swift-corelibs-dev mailing list >> swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev >> <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
