First off, I'm still learning out how to debate at this speed, sorry for the slow replies!
On Wed, Dec 14, 2016 at 9:32 PM, Kevin Ballard <ke...@sb.org> wrote: > On Wed, Dec 14, 2016, at 05:54 PM, Brian King wrote: > > Obj-C compatibility certainly is one reason to use NSObject, but perhaps a > bigger reason is because you're subclassing some framework-provided class, > like UIView or UIViewController. Just because I'm subclassing > UIViewController doesn't mean I want my controller's API to be subject to > Obj-C method dispatch unnecessarily. > > And even in the cases where I'm subclassing NSObject for Obj-C > compatibility, that doesn't mean that most of the calls to my object are > coming from Obj-C. All that means is that at least one place my object is > used is Obj-C, and 99% of the uses might be Swift. Or if I'm writing a > library, it might mean that I simply want to preserve Obj-C compatibility > in case a client wants it, even though I expect my clients to be primarily > Swift (For example, this is how postmates/PMHTTP is written; > Obj-C–compatible, but the expectation is most clients will probably be > Swift). > It's interesting, your library has very few non-final methods, because most of your classes are `final`. it's great to have this option, and as a result, it is very easy to write performant code. It is very wordy to write runtime friendly code. I think I value these optimizations less than you, to me it feels like it's pre-mature optimization, especially given how easy it is to opt into Static dispatch. > > > > Interaction with Obj-C runtime machinery stuff like KVO should be > opt-in. In Obj-C it's ad-hoc, many classes support it for properties but > many also don't, and very few properties have their KVO conformance > documented. I don't view having to mark my properties as `dynamic` to > participate in KVO to be a problem with Swift but rather a feature. It > tells the reader that this property supports KVO. > > > > This is an interesting point, and it would be an interesting semantic. > > However in practice, the majority of NSObject code is imported from > > obj-c, and it's generated interface does not follow this convention. > > Just because framework classes don't follow this convention doesn't mean > it's not a valuable convention to have in code written in Swift. There's a > lot of things that Swift does better than Obj-C, and that you don't get > when using an API imported from Obj-C, but that's not a reason to not do > those things. > > > Also, it's strange to conflate how something was dispatched and if it > > supported KVO. I think property delegates will be the future here and > > enable some exciting contracts if adopted. > > > > Another approach is to just make it easier to opt into the full obj-c > > machinery. The addition of a class or extension level `dynamic` > > keyword would be great. If we could get buy in on this, then the > > debate becomes if NSObject should default to `dynamic` or not. > > I don't think we should ever make it possible to mark an entire class as > `dynamic`. This just reintroduces the Obj-C problem, where many properties > support KVO, but not all, and there's no indication on the property itself > as to whether it supports it. > This would just be short hand for adding the `dynamic` keyword in front of every variable and method, so shy of the already existing computed property getter case, all of the properties should just work. > -Kevin Ballard > > > Brian > > > > > > > > -Kevin Ballard > > > > > > On Wed, Dec 14, 2016, at 03:15 PM, Brian King via swift-evolution > wrote: > > >> I wanted to follow up to a blog post I wrote about Message Dispatch in > > >> Swift — https://www.raizlabs.com/dev/2016/12/swift-method-dispatch. I > > >> mentioned some changes to NSObject that didn’t result in any > > >> objections, so I thought it was time to see what the SE mailing list > > >> thought. > > >> > > >> I’ve read a few conversations on SE mailing list that have morphed > > >> into abstract conversations about dynamic vs static dispatch. I want > > >> to focus specifically on how Swift NSObject subclasses behave. > > >> > > >> I think that there are 2 changes that will result in fewer bugs and > > >> will not have a substantial impact on performance: > > >> > > >> > > >> ## Remove Table Dispatch from NSObject > > >> > > >> NSObject subclasses use table dispatch for the initial class > > >> declaration block. I think that using message dispatch for NSObject > > >> subclasses everywhere will result in a much more consistent developer > > >> experience. > > >> > > >> ## Block NSObject Visibility Optimizations > > >> > > >> Swift upgrades method dispatch to final when the compiler can prove > > >> that the method is not subclassed. I would like to see Swift be more > > >> careful about the impact of these optimizations on message dispatch, > > >> and consider message dispatch non-upgradable. > > >> > > >> > > >> I thought it would help to frame this choice as a trade-off between > > >> Swift’s goals of safe, fast, and expressive. > > >> > > >> ## Safe > > >> > > >> Always using message dispatch for NSObject subclasses will fix a class > > >> of runtime errors in framework features that are designed around > > >> message passing (e.g. KVO). Arguments against using dynamic features > > >> like this are valid, but Cocoa frameworks still use dynamic features > > >> and the above behaviors result in actual bugs. As a bonus, this will > > >> resolve SR-584, where a table-dispatched method that is overridden by > > >> a message dispatch method doesn’t behave correctly. > > >> > > >> ## Fast > > >> > > >> The above changes will result in slower dispatch in NSObject > > >> subclasses. However, I don't think that these dispatch changes > > >> actually have a tangible impact on performance. Most NSObject > > >> subclasses sit on top of a lot of `objc_msgSend`, and if there is a > > >> specific hot spot, it would still be optimizable via the final > > >> keyword. > > >> > > >> ## Expressive > > >> > > >> Using table dispatch for NSObject without any source indication or > > >> library documentation is not very expressive. I think it’s important > > >> to weigh table dispatch behavior against all of the framework > > >> documentation and developer experience that assume message dispatch. > > >> This will also eliminate the need for a lot of `@objc` and `dynamic` > > >> annotations that are often inconsistently applied depending on if they > > >> are needed in the scope they are defined in (e.g. class vs extension). > > >> > > >> > > >> If this idea shows promise, I’d be glad to formalize a Swift Evolution > > >> Proposal and explore syntactic details. I think being able to flag a > > >> class with `dynamic` and applying this flag to `NSObject` may be the > > >> only syntactic change needed. However, it would be good to debate the > > >> merit of the behavior change before the syntax. > > >> > > >> > > >> Thanks! > > >> > > >> > > >> Brian King > > >> _______________________________________________ > > >> swift-evolution mailing list > > >> swift-evolution@swift.org > > >> https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution