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 is where it lives.
Thanks, Robert > On Dec 18, 2015, at 1:58 PM, Tony Parker <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 >
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
