<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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, <a href="https://github.com/rothomp3/swift-corelibs-foundation/tree/feature/NSXMLDocument" class="">https://github.com/rothomp3/swift-corelibs-foundation/tree/feature/NSXMLDocument</a> is where it lives.<div class=""><br class=""></div><div class="">Thanks,</div><div class="">Robert<br class=""><div><blockquote type="cite" class=""><div class="">On Dec 18, 2015, at 1:58 PM, Tony Parker <<a href="mailto:anthony.parker@apple.com" class="">anthony.parker@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Robert,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">- Tony</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 18, 2015, at 9:21 AM, Robert Stephen Thompson via swift-corelibs-dev <<a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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 <font face="Courier" class="">NSXMLNode</font> is <font face="Courier" class="">init(kind: NSXMLNodeKind, options: Int)</font>. In pure Swift, this <i class="">always</i> returns an NSXMLNode, not the appropriate subclass! Which, of course, means <font face="Courier" class="">as?</font> returns nil, <font face="Courier" class="">as!</font> (and <font face="Courier" class="">unsafeDowncast</font>) 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?<div class=""><br class=""></div><div class="">Thanks,</div><div class="">Robert Thompson</div><div class="">Software Engineer<br class="">WillowTree, Inc.®<br class=""><a href="http://willowtreeapps.com/" class="">willowtreeapps.com</a><br class=""> <span id="cid:04F0A8D2-F0EB-4FC5-9305-30B7966DFEA6@willowtree.lan" class=""><PastedGraphic-1.png></span></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=U7z7oSqRMSwdl2rYt9JJ4zIFaeg4R-2FxExg9xndDuCbwG4yAqzPkDteiTViT6V-2BTvZAbNDMfSbBWsfmp00iZPNbJyObQ6Dr59KOzIugJYcT1mRYsdyLWOSldDG-2Fl7vQDNBvOdWuKSZ-2BV-2Bp9SkLYYCLtYU0SH-2BqIsp6Ld3Vc1r1-2FF5roHk-2F7WYdBmiEwZEsYhMdHi6enMAEuC3HOtLXBCPdJWMOY0DiiwpwBEOWB4BtMU-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-corelibs-dev mailing list<br class=""><a href="mailto:swift-corelibs-dev@swift.org" class="">swift-corelibs-dev@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-corelibs-dev" class="">https://lists.swift.org/mailman/listinfo/swift-corelibs-dev</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></body></html>