5 ms·

Yes, but it’s not officially “condoned”, so it feels “out of place”. This is very individual, of course, but I don’t like bending the system to get patterns tha

Yes, but it’s not officially “condoned”, so it feels “out of place”. This is very individual, of course, but I don’t like bending the system to get patterns that are not “natively” supported. In Swift, you cannot currently create classes in code, enhance and swizzle, implement proper proxies. You couldn’t even load a nib without the ObjC runtime. Not even reflection. It’s telling what their priorities were with that language. What good is the language when you cannot implement most of the system frameworks (Cocoa, Core Data, etc.) without nasty hacks?

aplummer 9y ago
You’ve made some good points though I’ve found the reflection in swift since v2 to be sufficient for my day to day. I think the nib thing is a problem but in reverse, nibs needs to be swift so we can instantiate them with generics, this would be a game changer!
- LeoNatan25 9y ago
  Without reflection, you cannot create a nib system (or any general purpose archiving solution). For Encodable, they used hacks that were tantamount to macros in C, but that requires compile-time knowledge of the class/struct structure. That's not how nibs work.
aplummer 9y ago
Also I agree you can tell safety was the number one priority. However the positive is basically never getting runtime errors, except when interfacing with IB or obj-c even when people are programming in a hurry, which is nice for me.
- saagarjha 9y ago
  > However the positive is basically never getting runtime errors I don't quite think this is the "safety" that Swift aims for: rather, it prefers safety in the sense of failing fast and failing reliably if something goes wrong. Unwrapping nil and out of bounds array subscripting fall into this category of behavior.
- mpweiher 9y ago
  Hmm...like making every arithmetic operation a potential crash site?
- LeoNatan25 9y ago
  "Never getting runtime errors" is as far fetched as it can be. Consider Xcode suggesting developers use force unwrap ("!"), that leads to many more crashes with unexperienced developers than the ObjC message to nil paradigm. Subjectively, I have seen much more crashes in third-party software written in Swift than in ObjC (usually unwrapping or casting incorrectly), including in Apple's software. I cannot say if this is down to more inexperienced developers, less time allotted to experienced developers or a worse development model. I'd say a combination of the three.
  - aplummer 9y ago
    I didn’t know it suggested force unwrapping, I always have a linter to prevent it except for IBOutlets etc.
  - saagarjha 9y ago
    This might also be because Swift is more likely to crash than fail silently at runtime.
    - aplummer 9y ago
      I don’t see how this is possible, example?
saagarjha 9y ago
> In Swift, you cannot currently create classes in code, enhance and swizzle, implement proper proxies In pure Swift, that is. These are all possible if you reach into the Objective-C runtime, as I'm sure you know well. Overall, though, I do agree with you: I'm unsatisfied with the current reflection API in Swift and I really think that this is something that the core team should focus on some time.

aplummer 9y ago

You’ve made some good points though I’ve found the reflection in swift since v2 to be sufficient for my day to day. I think the nib thing is a problem but in reverse, nibs needs to be swift so we can instantiate them with generics, this would be a game changer!

LeoNatan25 9y ago
Without reflection, you cannot create a nib system (or any general purpose archiving solution). For Encodable, they used hacks that were tantamount to macros in C, but that requires compile-time knowledge of the class/struct structure. That's not how nibs work.

aplummer 9y ago

Also I agree you can tell safety was the number one priority. However the positive is basically never getting runtime errors, except when interfacing with IB or obj-c even when people are programming in a hurry, which is nice for me.

saagarjha 9y ago
> However the positive is basically never getting runtime errors I don't quite think this is the "safety" that Swift aims for: rather, it prefers safety in the sense of failing fast and failing reliably if something goes wrong. Unwrapping nil and out of bounds array subscripting fall into this category of behavior.
mpweiher 9y ago
Hmm...like making every arithmetic operation a potential crash site?
LeoNatan25 9y ago
"Never getting runtime errors" is as far fetched as it can be. Consider Xcode suggesting developers use force unwrap ("!"), that leads to many more crashes with unexperienced developers than the ObjC message to nil paradigm. Subjectively, I have seen much more crashes in third-party software written in Swift than in ObjC (usually unwrapping or casting incorrectly), including in Apple's software. I cannot say if this is down to more inexperienced developers, less time allotted to experienced developers or a worse development model. I'd say a combination of the three.
- aplummer 9y ago
  I didn’t know it suggested force unwrapping, I always have a linter to prevent it except for IBOutlets etc.
- saagarjha 9y ago
  This might also be because Swift is more likely to crash than fail silently at runtime.
  - aplummer 9y ago
    I don’t see how this is possible, example?

saagarjha 9y ago

> In Swift, you cannot currently create classes in code, enhance and swizzle, implement proper proxies In pure Swift, that is. These are all possible if you reach into the Objective-C runtime, as I'm sure you know well. Overall, though, I do agree with you: I'm unsatisfied with the current reflection API in Swift and I really think that this is something that the core team should focus on some time.