[swift-corelibs-dev] NSXMLNode and Friends

[Robert Stephen Thompson via swift-corelibs-dev]

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
 ___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSXMLNode and Friends

[Robert Stephen Thompson via swift-corelibs-dev]

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  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 
>> 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/>
>>  
>> 
>> ___
>> 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

Re: [swift-corelibs-dev] NSXMLNode and Friends

[Robert Stephen Thompson via swift-corelibs-dev]

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  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 
>> 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 >> <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 >>> <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 becaus

Re: [swift-corelibs-dev] Internal Tests

[Robert Stephen Thompson via swift-corelibs-dev]

If it doesn’t use it on Linux, it’s because I was mostly running tests in Xcode 
heh, and didn’t end up needing it in the end. On Linux, of course, I think 
you’d want @testable import Foundation. I’m not an Apple guy, though, I just 
happen to be the guy who wrote TestNSXMLDocument.swift! So if there is actually 
a reason not to use it, I’m not aware of it, but don’t necessarily take my word 
for it!

Thanks,
Robert Thompson
Software Engineer
WillowTree, Inc.®
willowtreeapps.com 

> On Mar 15, 2016, at 8:02 AM, Daniel Eggert via swift-corelibs-dev 
>  wrote:
> 
> Is it ok to use
>@testable import SwiftFoundation
> in tests? I'd like to test some internal code.
> 
> TestNSXMLDocument.swift uses this, but not on Linux. What's the reason for 
> this?
> 
> /Daniel
> 
> ___
> swift-corelibs-dev mailing list
> swift-corelibs-dev@swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev