What Happened to NSMethodSignature?
Bringing the Cocoa frameworks to Swift gave us a unique opportunity to look at our APIs with a fresh perspective. We found classes that we didn’t feel fit with the goals of Swift, most often due to the priority we give to safety. For instance, some classes related to dynamic method invocation are not exposed in Swift, namely
NSInvocationandNSMethodSignature.We recently received a bug report from a developer who noticed this absence. This developer was using
NSMethodSignaturein Objective-C to introspect the types of method arguments, and in the process of migrating this code to Swift, noticed thatNSMethodSignatureis not available.[…]
With a combination of protocols and generics, we have written Swift code to elegantly create and register HTTP handlers of varying types. This approach also lets the compiler guarantee type safety, while ensuring excellent runtime performance.
Seriously, someone asks for the functionality for dynamic dispatch and you say you can do the same thing with static code! No, you cannot. You can mimic the behavior.
Instead, you showed someone how to build a static registration table. Then you make the statement that it’s “type-safe” while using
Anyas the arguments to the public API fordispatchand using type coercion… that’s not type-safety. And let’s be honest, it’s really not that different then the validation one does for dynamic dispatch either.[…]
You see, and this is the trade-off that you never mention. You paint an extremely biased position without covering the full gambit of what is really needed to build and maintain a system like you are proposing. The reality, it sucks.
Not to mention the other things you can do with NSInvocation that can’t be mimicked with static code.
Update (2014-12-13): Daniel Luz:
I can only infer the use case from what was presented, but it seems to me you solved the wrong problem here
1 Comment RSS · Twitter
First we create crippled languages that can't express our needs, then we create cowboy workarounds for expressing those needs badly, and finally we cripple ourselves with all the back-patting for creating such ingeniously clever "solutions" to problems that shouldnt've have existed in the first place.
If only we could all just agree that Lisp and Dylan were right to begin with, and just be done with it...
