5 ms·

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

• pohl 12y ago
  Along that line of thought, it looks like there are beginnings of a mirror-based reflection implementation already in there. It appears to only be there for Playground at the moment. http://stackoverflow.com/questions/24060667/does-swift-support-reflection http://stackoverflow.com/questions/24060667/does-swift-suppo...
  • pstop 12y ago
    Yea, I noticed this in the undocumented API's, but haven't played much with it. It's definitely cleaner than C#'s reflection implementation, but more limited as well. Though for most uses, knowing the limitations solves most of the issues the OP has.
    • astigsen 12y ago
      This presentation covers some of the reflection API in Swift: http://www.realm.io/news/swift-unchartered-territory-swift-intro-and-internals/ http://www.realm.io/news/swift-unchartered-territory-swift-i... While it is clearly still somewhat limited, it does seem like there is potential for it to evolve into a really robust reflection API.
      • Glide 12y ago
        I disagree. Right now it doesn't seem like a lot of things aren't possible in swift unless there is a LOT of undocumented 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.
    • bigdubs 12y ago
      I am not sure how clean the reflect() function is in swift right now as it stands. 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.
  • josephlord 12y ago
    Thanks looks interesting. I do suspect that it will stay playground only because for compiled code the data may not exist to work out the types of some values.
• Buckleyisms 12y ago
  This is true, and why I also filed bugs asking for a robust reflection and dynamic method compilation. Thankfully, they were duplicates. 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.
  • bigdubs 12y ago
    monkey patching specifically is pretty heinous in c# but can be done. you should avoid monkey patching in almost any situation though. 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.
    • leonatan 12y ago
      Care to share some resources on C#/.net monkey patching? Tia