And +1 for documentation. Do you have any guide about how dynamic casting actually works? It would perfectly fit there.
And if there is no public guide, I think it would be great to have one because as far as I see from the code, there are many different scenarios and different behaviors for each scenario, and implementations are implicitly affected by that. I had to follow stack trace on crash, tried to find the method corresponding to the ObjC type case, find them in source code and compare :) On Wed, 8 Jun 2016 at 22:17, Yavuz Nuzumlalı <manuya...@gmail.com> wrote: > Hmm, interesting. > > So, we can say that NSProxy class, which is the base structure for > implementing proxy pattern, will not work for a Swift type, right? And I > simply can't use proxy pattern if real object can be a Swift type. > > In my use case, I have a framework, and I want to switch developer's some > delegate object with my NSProxy standin, listen delegate method myself, > then forward to the developer's original delegate object. > > It was working without any issues for delegate objects which are > Objective-C classes. But, it fails for Swift types because dynamic casting > does not work anymore. > > So, do you have any suggestions about how can I handle this interception > functionality without NSProxy? > > I don't want to do swizzling :) > > Thanks for the explanations! > > On Wed, 8 Jun 2016 at 21:13, Jordan Rose <jordan_r...@apple.com> wrote: > >> >> On Jun 8, 2016, at 10:52, Joe Groff via swift-dev <swift-dev@swift.org> >> wrote: >> >> >> On Jun 8, 2016, at 12:44 AM, Yavuz Nuzumlalı via swift-dev < >> swift-dev@swift.org> wrote: >> >> Hi all, >> >> swift_dynamicCastClassUnconditional and >> swift_dynamicCastObjCClassUnconditional methods behave differently while >> verifying casting. >> >> swift_dynamicCastObjCClassUnconditional method calls -isKindOfClass: >> method before falling back to object_getClass function. >> >> swift_dynamicCastClassUnconditional method calls swift_dynamicCastClass >> method which calls _swift_getClassOfAllocated method which calls directly >> object_getClass function. >> >> This causes problems if underlying object is an NSProxy subclass. >> >> NSProxy class does not implement -isKindOfClass: method, so calls to this >> method are forwarded to the real object through -forwardInvocation: method, >> which causes -isKindOfClass: method to return answer according to the real >> object's class. >> >> However, object_getClass function directly accesses to the metadata of >> the given object, so it returns NSProxy subclass. >> >> I think this is a conflicting behavior, and I think >> swift_dynamicCastClassUnconditional method should also verify first using >> -isKindOfClass: method, in order to provide consistency. >> >> >> This is intentional, since NSProxy instances are generally expected to be >> standins for the proxied object. Important Cocoa idioms break down if the >> "real" class is exposed instead of the class a proxy pretends to be. >> >> >> For a little more detail, Swift relies on a bit more information about >> layout of both instances and classes than Objective-C does, so an NSProxy >> stand-in wouldn't work for a Swift type. (And by "wouldn't work" I mean >> "would crash your program".) However, for an Objective-C type, all accesses >> Swift does will always go through the Objective-C runtime, so it's safe to >> use an Objective-C-style proxy, and indeed some Cocoa APIs expect this. >> >> This is probably something we could stand to document more explicitly, >> but I'm not sure where. >> >> Jordan >> >>
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
