Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dynamic Swift

mjtsai.com

Post reply on HN
Print view View original

31–40 of 54 posts

Re: Dynamic Swift

#31

Post by refulgentis »

drewcrawford wrote: post #26
refulgentis wrote: post #8

Earlier quoted context omitted.

The Objective-C old guard has had a very hard time dealing with Swift. For a couple years now, every 3 months they have another blog post hand-wringing about what they used to do in Objective-C, how they can't in Swift, with the implicit warning this is worrisome and _needs_ to be reimplemented in Swift, or Swift isn't a serious contender long-term. Most of the of the community seems to have moved on, with the unders…

So, I'm deeply involved in Swift, in the sense that: I write the odd compiler feature. From my vantage point it seems to be the opposite of your analysis. While it is true that ObjC's dynamism has all kinds of problems we want to avoid, we're also running into lots of cases where the obvious solution is dynamism, and the other solutions aren't obvious. One concrete example I can offer you is NSCoding, which is being…

There's definitely some nuance to this situation – I didn't mean to imply dynamic features aren't needed, or have no place. While writing my comment, there was a nagging voice in my head saying "What about Swift Foundation?"

What I meant to communicate was that there's a histrionical air to most of the commentary that is unfounded. We don't need to be able to reimplement Rails, or KVO, or Core Data – we need to come up with new ways to solve those problems with an approach like you're seeing working in practice, a more structured dynamism. And for what it's worth, all of those problems deserve another try at an answer. They're some of the most tricky parts of the platform.

Re: Dynamic Swift

#32

Post by mikeash »

drewcrawford wrote: post #26
refulgentis wrote: post #8

Earlier quoted context omitted.

The Objective-C old guard has had a very hard time dealing with Swift. For a couple years now, every 3 months they have another blog post hand-wringing about what they used to do in Objective-C, how they can't in Swift, with the implicit warning this is worrisome and _needs_ to be reimplemented in Swift, or Swift isn't a serious contender long-term. Most of the of the community seems to have moved on, with the unders…

So, I'm deeply involved in Swift, in the sense that: I write the odd compiler feature. From my vantage point it seems to be the opposite of your analysis. While it is true that ObjC's dynamism has all kinds of problems we want to avoid, we're also running into lots of cases where the obvious solution is dynamism, and the other solutions aren't obvious. One concrete example I can offer you is NSCoding, which is being…

Regarding XCTest, could you extend Mirror to provide methods as well as fields? That seems to me like it would be a more natural solution.

Re: Dynamic Swift

#33

Post by mikeash »

ebbv wrote: post #16

I don't want to call someone I don't know a bad developer, but as a general rule if software is moving more towards safety and reliability and you are resisting that change that's a sign there's a problem with your habits and preferences. Not that the decisions being made are bad. Swift is not a perfect language, there's a lot of low hanging fruit (some of which is being dealt with in Swift 3), but it's lack of suppo…

People rarely if ever argue that they want to write less reliable software because it's easier. The typical argument is that type safety does not necessarily translate into programmer safety, and that the resulting programs are more safe and more reliable.

I don't tend to agree with those arguments (at least for now, I reserve the right to change my mind again) but I don't think that it's useful to just dismiss them based on their basic shape.

Re: Dynamic Swift

#34

Post by chris_7 »

eunoia wrote: post #30
chris_7 wrote: post #28

Earlier quoted context omitted.

Other than "we want to rewrite Foundation/XCTest in Swift", why do we need XCTest or NSCoding implemented in Swift? Neither is particularly Swifty - many things in Foundation that ought to be structs are classes, for example, and there's the nonsensical duplication of String/NSString/NSMutableString and the other containers. If you want a Swifty testing framework, just pass a bunch of test functions to a function, or…

> why do we need XCTest or NSCoding implemented in Swift? Linux compatibility. As long as Foundation is written in Obj-C it can't be ported.

I get that it's necessary for running them on Linux, I just question the need to do that in the first place, instead of creating new, Swiftier APIs. NSURLSession's delegates have optional requirements, for example, which aren't supported in pure Swift code.

Re: Dynamic Swift

#35

Post by drewcrawford »

mikeash wrote: post #32
drewcrawford wrote: post #26

Earlier quoted context omitted.

So, I'm deeply involved in Swift, in the sense that: I write the odd compiler feature. From my vantage point it seems to be the opposite of your analysis. While it is true that ObjC's dynamism has all kinds of problems we want to avoid, we're also running into lots of cases where the obvious solution is dynamism, and the other solutions aren't obvious. One concrete example I can offer you is NSCoding, which is being…

Regarding XCTest, could you extend Mirror to provide methods as well as fields? That seems to me like it would be a more natural solution.

For what it's worth, that's my preferred solution in the long-term too.

Speaking narrowly about the XCTest case:

* It doesn't actually require runtime dynamism (since you have a finite number of tests that can be statically enumerated). Following the principle of least power, don't do it if you don't have to.

* A runtime-dynamism-based solution would require `dynamic` sprinkled on function definitions which would be a departure from source compatibility with Darwin XCTest which relies on the superclass and @objc inference on methods.

* Mirror offers reads but not writes, and there is some sense that offering the ability to mutate through Mirror is uncharted design territory.

Then there is debate about whether other "dynamic" cases can also be solved with static analysis. I am in the "probably not all of them" camp, but that still leaves some of them, and it would be good to study that boundary condition in more detail.

With sufficiently robust static analysis you "can" implement your mirror trick for example (by code-generating a bigass extension to Mirror that just returns statically-analyzed data). Somebody will do that, and so I think upstream will be following how well it works out for them and letting the larger community build the case for or against the feature.

Re: Dynamic Swift

#36

Post by dottrap »

chris_7 wrote: post #29
dottrap wrote: post #25

Earlier quoted context omitted.

What's going on here is Brent Simmons has been posting a series of blog articles expressing concern that very useful dynamic features used in Obj-C to great effect cannot be currently done in pure Swift. And many of the old guard that is knowledgable in how Obj-C+Cocoa is implemented and have built their own powerful things on top of it are also expressing their same concern that Swift has not addressed how these thi…

> Responder Chain Protocols, or even a superclass. > NSUndoManager Closures. Even Apple has moved away from target/selector for new APIs in favor of blocks. > Key-Value-Coding/Key-Value-Observing/Cocoa Bindings An equivalent is easily implementable in pure Swift, see ReactiveCocoa's PropertyType/MutablePropertyType, and I'm sure someone has packaged something similar as a µframework so that you don't need to add all…

It doesn't sound like you've read any of the articles. There are details and tradeoffs and limitations found by the people talking about them. And there is a massive knowledge vacuum because if there is a good solution, it's not something that is obvious and well discussed by Apple. Ignoring and dismissing them doesn't make them actually go away.

Here's two on just the Responder chain: http://inessential.com/2016/05/17/responder_chain_followup http://shapeof.com/archives/2016/5/dynamic_swift.html

The bigger point (which is in that first Brent Simmons link) is that people have built all sorts of frameworks and tools over the past 20 years depending using of the dynamic features of Obj-C. Some are Apple's like all the above plus others like Interface Builder and XCTest, but other people have built their own things too that rely on the same concepts. How do these people move forward in a Swift world?

None of these people are arguing that Swift is terrible and going back to Obj-C. They are trying to use Swift. They are only interested in solving the problems they have (and well). When Swift fails to solve a problem or is far worse than its predecessor, there is a problem.

Not everybody can nonchalantly throw their stuff overboard like you are willing to do with Core Data.

Re: Dynamic Swift

#37

Post by [deleted] »

refulgentis wrote: post #31
drewcrawford wrote: post #26

Earlier quoted context omitted.

So, I'm deeply involved in Swift, in the sense that: I write the odd compiler feature. From my vantage point it seems to be the opposite of your analysis. While it is true that ObjC's dynamism has all kinds of problems we want to avoid, we're also running into lots of cases where the obvious solution is dynamism, and the other solutions aren't obvious. One concrete example I can offer you is NSCoding, which is being…

There's definitely some nuance to this situation – I didn't mean to imply dynamic features aren't needed, or have no place. While writing my comment, there was a nagging voice in my head saying "What about Swift Foundation?" What I meant to communicate was that there's a histrionical air to most of the commentary that is unfounded. We don't need to be able to reimplement Rails, or KVO, or Core Data – we need to come…

[deleted]

Re: Dynamic Swift

#38

Post by Razengan »

refulgentis wrote: post #11
Razengan wrote: post #10

Earlier quoted context omitted.

I do hope Apple unveils a unified protocol-oriented framework for both MacOS and iOS. One that, when necessary, keeps Swift in mind before Objective-C.

Definitely - it would be awesome , but way ahead of schedule, if they're thinking about a true UXKit landing with ABI stability and "finished" generics in Swift 4.

Well, considering that Swift was in development for 4? years or so before they announced it, it would make sense if they've already been working on a new API platform for a while. Something that pleasantly unites iOS+MacOS+Swift on the developer side, while letting those operating systems retain their differences and strengths on the user side.

Re: Dynamic Swift

#39

Post by mikeash »

drewcrawford wrote: post #35
mikeash wrote: post #32

Earlier quoted context omitted.

Regarding XCTest, could you extend Mirror to provide methods as well as fields? That seems to me like it would be a more natural solution.

For what it's worth, that's my preferred solution in the long-term too. Speaking narrowly about the XCTest case: * It doesn't actually require runtime dynamism (since you have a finite number of tests that can be statically enumerated). Following the principle of least power, don't do it if you don't have to. * A runtime-dynamism-based solution would require `dynamic` sprinkled on function definitions which would be…

It's a really interesting point that you don't need runtime dynamism for this so maybe that shouldn't be the go-to solution. It's easy to just decide to do it that way because that's how it works currently.

Re: Dynamic Swift

#40

Post by phink »

chris_7 wrote: post #29
dottrap wrote: post #25

Earlier quoted context omitted.

What's going on here is Brent Simmons has been posting a series of blog articles expressing concern that very useful dynamic features used in Obj-C to great effect cannot be currently done in pure Swift. And many of the old guard that is knowledgable in how Obj-C+Cocoa is implemented and have built their own powerful things on top of it are also expressing their same concern that Swift has not addressed how these thi…

> Responder Chain Protocols, or even a superclass. > NSUndoManager Closures. Even Apple has moved away from target/selector for new APIs in favor of blocks. > Key-Value-Coding/Key-Value-Observing/Cocoa Bindings An equivalent is easily implementable in pure Swift, see ReactiveCocoa's PropertyType/MutablePropertyType, and I'm sure someone has packaged something similar as a µframework so that you don't need to add all…

> Safety

if (indexPath == 3) {...} Results in a warning in Objective C, none in Swift. Did you see that .row is missing?

> Productivity

How is (notification.userInfo?[UIKeyboardFrameBeginUserInfoKey] as? NSValue)?.CGRectValue() more productive than [[notification userInfo][UIKeyboardFrameBeginUserInfoKey] CGRectValue]

Swift makes me waste my time on trivial things.

Post reply on HN