Honestly a lot of the cases presented here would be accomplished by a robust reflection API and some form of dynamic method compilation.
These are both things I haven't seen in Swift yet and will miss dearly from .net/C#.
These are both things I haven't seen in Swift yet and will miss dearly from .net/C#.
http://stackoverflow.com/questions/24060667/does-swift-suppo...
While it is clearly still somewhat limited, it does seem like there is potential for it to evolve into a really robust reflection API.
Dynamic method compilation that you would need to make an equivalent of DynamicProxy just doesn't seem possible. What's funny is that the #1 thing I would state is not possible in Swift is Core Data.
reflect(User()) requires me to new up an instance of the object to reflect. This is a static(ish) language right? Why do I need to reflect a specific instance?
In c# you just go typeof(User).GetProperties|GetMethods|GetFields etc. You don't need to new up an object, all the required information is stored as metadata for the type after compilation.
I understand in a universe where you can dynamically add methods/fields/properties etc. to a type you'd want the specific instance at runtime to reflect, but as far as I know Swift does away with this dynamism on purpose.
But not all of the cases can be accomplished using these techniques, and even those that can, it's often more code.
The ability to reason about which methods are getting called at runtime has been a powerful tool since the beginning of iOS development, and in Mac and NeXTStep development before that. It would be a shame to lose it.
one point of yours that i don't understand is the ability to reason about what methods are being called without message passing. if you understand the inheritance hierarchy it should be pretty easy to think about what 'version' of a method is being called? between the known inheritance path and a call stack at runtime this isn't something i find myself missing from obj-c.
where the call stack / inheritance hierarchy does get messy is in calling virtual methods from within constructors, which is a bad practice generally, and something apple devs touch on in the wwdc demos.