3 ms·

I guess Swift still isn't widely adopted inside Apple. Or it could be that CareKit was started before Swift. Anyone know for sure?

by Cyph0n 11y ago

icpmacdo 11y ago
The sample app is written in Swift, https://github.com/carekit-apple/CareKit/tree/master/Sample/OCKSample https://github.com/carekit-apple/CareKit/tree/master/Sample/...
guessbest 11y ago
Apple has publically recommended Objective-C code to not call Swift libraries, but rather advises Swift calling Swift frameworks or Swift calling Objective-C frameworks.
- Cyph0n 11y ago
  Ah, I see. That makes sense.
- pducks32 11y ago
  Oh I didn't know that. It still seems weird. Objective-C has always been hard for me to read and yet I love reading code—especially Apple's—so I guess the struggle will continue. Even if that means I can't really contribute to this.
  - cloudjacker 11y ago
    runOnSentencesAsMethodNamesDidNotAppealToYou ?
    - sjwright 11y ago
      That's the best bit, and makes reading blocks of code incredibly efficient. You can observe a method being called like [table allowsMultipleSelectionDuringEditing:YES] And even though you might not remember that UITableView method, once you read it you immediately know what it does, often saving you a round trip to the docs.
      - cloudjacker 11y ago
        > often saving you a round trip to the docs that's optimistic those methods rarely do exactly what you think, they can be an overloaded version of another method and more frequently there is another method with a similar method name, or one is singular and one is plural and it becomes very inefficient because the method names look the same, the exact reason why the english language has spaces and punctuation to begin with
        sjwright 11y ago
        Well duh, obviously. They're not going to concatenate entire paragraphs of documentation into the method name. Like so many things it's a matter of degrees. If the method was called table.multiSel() then you'll be more likely to need to consult the docs. It's not optimistic in my experience. Much of the time when doing code review or bug hunting other people's code, it's less about knowing exactly what a particular method does, as much as being able to rapidly estimate your way to relevant areas. If nothing else, verbose names can make it faster to ignore irrelevant code.
- JakaJancar 11y ago
  Where was that?
rizwan 11y ago
To further expand on Apple's recommendation to not make Swift libraries just yet — It's also an matter of compatibility. You could certainly make a Swift framework, but given that Swift as a language is changing every 6 months or so right now, it doesn't make sense to make a framework using Swift. You could easily hold up another project if you haven't changed your Swift code to the latest, or the opposite is true as well: Your Swift framework is up-to-date with the latest language, but the app using your framework is not, etc.

I guess Swift still isn't widely adopted inside Apple. Or it could be that CareKit was started before Swift. Anyone know for sure?

by Cyph0n 11y ago

I guess Swift still isn't widely adopted inside Apple. Or it could be that CareKit was started before Swift. Anyone know for sure?

icpmacdo 11y ago

The sample app is written in Swift, https://github.com/carekit-apple/CareKit/tree/master/Sample/OCKSample https://github.com/carekit-apple/CareKit/tree/master/Sample/...

guessbest 11y ago

Apple has publically recommended Objective-C code to not call Swift libraries, but rather advises Swift calling Swift frameworks or Swift calling Objective-C frameworks.

Cyph0n 11y ago
Ah, I see. That makes sense.
pducks32 11y ago
Oh I didn't know that. It still seems weird. Objective-C has always been hard for me to read and yet I love reading code—especially Apple's—so I guess the struggle will continue. Even if that means I can't really contribute to this.
- cloudjacker 11y ago
  runOnSentencesAsMethodNamesDidNotAppealToYou ?
  - sjwright 11y ago
    That's the best bit, and makes reading blocks of code incredibly efficient. You can observe a method being called like [table allowsMultipleSelectionDuringEditing:YES] And even though you might not remember that UITableView method, once you read it you immediately know what it does, often saving you a round trip to the docs.
    - cloudjacker 11y ago
      > often saving you a round trip to the docs that's optimistic those methods rarely do exactly what you think, they can be an overloaded version of another method and more frequently there is another method with a similar method name, or one is singular and one is plural and it becomes very inefficient because the method names look the same, the exact reason why the english language has spaces and punctuation to begin with
      - sjwright 11y ago
        Well duh, obviously. They're not going to concatenate entire paragraphs of documentation into the method name. Like so many things it's a matter of degrees. If the method was called table.multiSel() then you'll be more likely to need to consult the docs. It's not optimistic in my experience. Much of the time when doing code review or bug hunting other people's code, it's less about knowing exactly what a particular method does, as much as being able to rapidly estimate your way to relevant areas. If nothing else, verbose names can make it faster to ignore irrelevant code.
JakaJancar 11y ago
Where was that?

rizwan 11y ago

To further expand on Apple's recommendation to not make Swift libraries just yet — It's also an matter of compatibility. You could certainly make a Swift framework, but given that Swift as a language is changing every 6 months or so right now, it doesn't make sense to make a framework using Swift. You could easily hold up another project if you haven't changed your Swift code to the latest, or the opposite is true as well: Your Swift framework is up-to-date with the latest language, but the app using your framework is not, etc.