3 ms·

Back to the Mac? 12 features from iOS I'd like to see in Lion

34 points by barredo 16y ago

pmjordan 16y ago
The other points seem pretty valid [1] but points 1-3 and 8 appear to be prime candidates for category extensions. I'm aware of their drawbacks but they could be applied here with little inconvenience and they dilute an otherwise interesting article somewhat. (I almost gave up reading after reading the first 3 complaints in what appeared to be pure API bitching) [1] I have almost zero experience with "grown-up" Cocoa and plenty with iOS, but assuming their factual correctness, they seem valid concerns.
- pornel 16y ago
  API is a very important aspect of a platform, so I think "API bitching" is still valid complaint. Improvements in Cocoa Touch make parts of Mac Cocoa look old and needlessly complicated. That's definitely a problem that needs addressing. Categories can patch some of that, but you still have to write ugly code once, and categories are not as elegant as fix in the API itself (e.g. you have to use odd/prefixed method names in categories to avoid collision with potential future API).
  - pmjordan 16y ago
    Improvements in Cocoa Touch make parts of Mac Cocoa look old and needlessly complicated. That's definitely a problem that needs addressing. If this is a major general point, it should probably be explained as such; picking 4 specific examples and discussing them as free-standing, independent issues didn't convey a greater issue of "the Cocoa interfaces are too verbose for 95% of use cases" to me. If it's literally 4 methods, even namespace-prefixed category extensions seem a pretty attractive option to me. Granted, clarifying that would have reduced the list to 9 points rather than 12, making it 25% less linkbaity.
  - alextgordon 16y ago
    Categories can patch some of that, but you still have to write ugly code once, and categories are not as elegant as fix in the API itself (e.g. you have to use odd/prefixed method names in categories to avoid collision with potential future API). If the API is really obvious then this doesn't matter, since the category will simply replace the API method with something that does exactly the same thing. For example, there's no real need to prefix a category implementation of -cgColor because it couldn't conceivably do anything else. If it really bothers you, then you can use the runtime to load methods into NSColor, first checking to see if they exist.
- Zev 16y ago
  [1] I have almost zero experience with "grown-up" Cocoa and plenty with iOS, but assuming their factual correctness, they seem valid concerns. So you've never experienced weird bugs because Apple added a method that had the same name as your category that did almost the same thing, but not quite? :)
  - pmjordan 16y ago
    Namespace prefixing is a bit on the ugly side, but does get the job done.
    - deleted 16y ago
      [deleted]
deleted 16y ago
[deleted]
spot 16y ago
I wish Lion would protect me from pornography and dangerous apps like iOS does.
- ryanpetrich 16y ago
  I assume you've disabled Safari then?

34 points by barredo 16y ago

The other points seem pretty valid [1] but points 1-3 and 8 appear to be prime candidates for category extensions. I'm aware of their drawbacks but they could be applied here with little inconvenience and they dilute an otherwise interesting article somewhat. (I almost gave up reading after reading the first 3 complaints in what appeared to be pure API bitching) [1] I have almost zero experience with "grown-up" Cocoa and plenty with iOS, but assuming their factual correctness, they seem valid concerns.

pornel 16y ago
API is a very important aspect of a platform, so I think "API bitching" is still valid complaint. Improvements in Cocoa Touch make parts of Mac Cocoa look old and needlessly complicated. That's definitely a problem that needs addressing. Categories can patch some of that, but you still have to write ugly code once, and categories are not as elegant as fix in the API itself (e.g. you have to use odd/prefixed method names in categories to avoid collision with potential future API).
- pmjordan 16y ago
  Improvements in Cocoa Touch make parts of Mac Cocoa look old and needlessly complicated. That's definitely a problem that needs addressing. If this is a major general point, it should probably be explained as such; picking 4 specific examples and discussing them as free-standing, independent issues didn't convey a greater issue of "the Cocoa interfaces are too verbose for 95% of use cases" to me. If it's literally 4 methods, even namespace-prefixed category extensions seem a pretty attractive option to me. Granted, clarifying that would have reduced the list to 9 points rather than 12, making it 25% less linkbaity.
- alextgordon 16y ago
  Categories can patch some of that, but you still have to write ugly code once, and categories are not as elegant as fix in the API itself (e.g. you have to use odd/prefixed method names in categories to avoid collision with potential future API). If the API is really obvious then this doesn't matter, since the category will simply replace the API method with something that does exactly the same thing. For example, there's no real need to prefix a category implementation of -cgColor because it couldn't conceivably do anything else. If it really bothers you, then you can use the runtime to load methods into NSColor, first checking to see if they exist.
Zev 16y ago
[1] I have almost zero experience with "grown-up" Cocoa and plenty with iOS, but assuming their factual correctness, they seem valid concerns. So you've never experienced weird bugs because Apple added a method that had the same name as your category that did almost the same thing, but not quite? :)
- pmjordan 16y ago
  Namespace prefixing is a bit on the ugly side, but does get the job done.
  - deleted 16y ago
    [deleted]

deleted 16y ago

[deleted]

spot 16y ago

I wish Lion would protect me from pornography and dangerous apps like iOS does.

ryanpetrich 16y ago
I assume you've disabled Safari then?