@brentsimmons Also, wrt #3, I’d argue that’s far less important.
I’m with you on #1 and #2 though. I’d kill for annotations in Swift.
-
-
- View other replies
-
@caseyliss #3 is last on the list partly because it’s the least important. #1 and #2 definitely belong together. - View other replies
-
-
-
@brentsimmons Isn’t it the unsafe and even a bit “hacky” way of programming that we are trying to avoid using Swift? -
@nsmeme Yes. But it’s also what powers our frameworks, which make writing iOS and Mac apps such a joy. -
@brentsimmons I can agree about the joy. I hope there is another way. More dynamic Swift - maybe - but not in a way the ObjC was. -
@brentsimmons ObjC *is*. (Freudian slip?)
-
-
-
@brentsimmons #1 and #2 would be solved by C#’s reflection. #3 is… not as simple. But can be done. See here: https://msdn.microsoft.com/en-us/library/dd264741.aspx … - View other replies
- Show more
-
-
-
@brentsimmons I don't think there's much debate about reflection. Swift needs & Go has excellent reflection in a very static language. 1/ -
@brentsimmons But beyond that, in my experience, 90% of "dynamics" in Cocoa are KVC/O of classes/properties that are known at compile time. -
@brentsimmons Agree that Storyboards are the future, so Swift must support them. But that's different than objc_addClass, which is rare. - Show more
-
-
@brentsimmons IMO too much "wasn’t known at comp time", it often act is, be it KVC or perform::, just in a diff 'lang' (model, template etc)
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
Brent Simmons
Casey Liss

Oktawian Chojnacki
Rob Napier
Helge Heß