Archive for December 21, 2015

Monday, December 21, 2015 [Tweets] [Favorites]

Swift Proposal for Default Final

Curt Clifton (tweet, comments):

That is, the suggestion is that subclassing classes and overriding methods should be implicitly banned unless the framework author takes specific action to permit such indignities. The idea has evolved a bit over the last two+ weeks, to suggest that this implicit ban only apply across module boundaries.

I was shocked to find many members of the Swift team at Apple agreeing with this suggestion. When I’d mentioned the suggestion to co-workers and to friends in the app development community, to a person they said it was ridiculous.

Greg Titus:

I can’t prove any causation, but I would certainly argue that the dynamic nature and possible overridability of even things that Apple doesn’t specifically intend to allow overriding is one of the primary reasons why AppKit has survived for 20+ years and spawned arguably the most successful application framework in history in UIKit. On the other hand, efficiency and safety have rarely been major issues.

TLDR: I don’t think using the design trade-offs of Array (which is, after all, a value type and can’t be subclassed anyway) inside stdlib, can be very usefully broadened to apply to reference types in application frameworks.

Jordan Rose:

Supporting arbitrary code injection into someone else’s framework is a non-goal for Swift, perhaps even an anti-goal. […] If you replace a method on someone else’s class, you don’t actually know what semantics they’re relying on. Of course Apple code will have bugs in it. Trying to patch over these bugs in your own code is (1) obviously not an answer Apple would support, but also (2) fraught with peril, and (3) likely to break in the next OS release.

Curt Clifton:

Presumably a goal for Swift is that application developers will use it to build user-facing apps for Apple’s platforms. And presumably a goal for Apple is that developers help promote Apple’s platforms by shipping apps that take advantage of the new OS features when they ship. I fear that you and others dramatically underestimate the difficultly of doing that. I acknowledge your three points. But understand that we are professionals trying to serve our mutual customers. Temporary hacks in the service of shipping is the nature of the business.

I don’t know how to make the case more strongly than I already have. This thread makes me worry that the team does not understand what it’s like for third party developers trying to serve our mutual customers.

Michael Buckley:

But if you’re working on a consumer app, I do think that it’s logical vtable dispatch is what you want most of the time. So in my experience, functions need to be virtual more often than not, and the C++ code I’ve seen would be shorter if you had to explicitly mark methods as nonvirtual rather than virtual.

Curt Clifton:

swizzling and aggressive subclassing are last resorts, but they are necessary in the current ecosystem.

We regularly ship multiple major products on OS release day. We know this stuff.

I could not agree with Clifton more strongly. It seems like there is a culture clash between the compiler developers, who want to increase the potential for optimization, and the app developers, who like things to be more flexible because they are building on top of an imperfect platform. Since Swift’s introduction, I have been arguing that message passing (i.e. the dynamic keyword) should be the default, rather than vtable dispatch. The idea of locking things down further, with final as the default, is insane.

Making code that is not the bottleneck faster is a small win compared with an increase in bugs that directly affect customers. Rose and Joe Groff are right that there are problems with patching. But if it’s temporary and done responsibly, it’s a good pragmatic solution. Bugs are inevitable, and sometimes it is months or years before they are fixed, so Apple should not stand in the way of people trying to mitigate them.

Wil Shipley:

It is a disturbing thought, but it’ll be a long time before frameworks are written in Swift.

I like Swift. It’s exciting to think of future frameworks that take full advantage of it. It’s scary, and ironic, to think about how this modern, safe language may actually lead to more brittle software.

Update (2015-12-22): Brent Royal-Gordon:

This means doing some dangerous overriding, yes. But a UI that breaks after an iOS upgrade is not nearly as dangerous to my business as a three-month delay while I reimplement half of UIKit because someone in Cupertino thought they knew what I need better than I do and turned off—or even worse, left turned off without a single thought—subclassing of UIBarButtonItem.

The bottom line is this: Your users like Swift’s strictures when they’re helpful. This stricture is not helpful. Library users don’t accidentally subclass things, and with the override keyword in Swift, they don’t accidentally override them either. And where it truly is important, for safety or for speed, to prevent subclassing, we already have final. Making it the default is less safety than suffering.

Jesse Larson:

My concern when I saw Swift was that it was done by compiler guys who don’t ship or maintain apps.

Jared Sinclair:

Final by default requires a lvl of transparency and perfection that Apple framework engineers cannot realistically provide

Update (2015-12-23): Curt Clifton and Drew Crawford suggest middleware as a possible solution.

Update (2016-01-08): See also: Accidental Tech Podcast.

Update (2016-01-09): Friedrich Markgraf:

Apple making framework bugs unfixable was my number one concern when Swift was announced.

Marcel Weiher:

Subclassing a type not intended for it may be unfortunate, it may be necessary/desirable. Either way it is fixable.

Not being able to subclass a class is not.

And when the new release comes there is time for 3rd parties to fix. This is different from not being able to fix.

How Gzip Trumps Everything

Greg Hurrell (tweet):

In short, if you try to eliminate redundancy by applying some kind of clever transformation or restructuring your data object before piping it to gzip, you will probably just do a crappy job of reimplementing gzip at the wrong layer of abstraction, and get worse results overall.

Property-Based Testing of a Synchronization Service

John Hughes et al. (PDF, via Hacker News):

File synchronization services such as Dropbox are used by hundreds of millions of people to replicate vital data. Yet formal models of their behavior are lacking. We present the first formal—and testable—model of the core behavior of a modern file synchronizer, and we use it to discover surprising behavior in two widely deployed synchronizers. Our model is based on a technique for testing nondeterministic systems that avoids requiring that the system’s internal choices be made visible to the testing framework.

Six Windows 10 Features Apple Should Steal

Julio Ojeda-Zapata:

For the longest time, Windows users have been able to position two windows side-by-side on their displays by dragging one to the right and the other to the left until each “snaps” into place. […] Ah, but Windows 10 has already upped the ante. Windows now permits snapping of four windows into a grid, which is useful on big monitors to create a dashboard of sorts. Windows 10 also allows placement of a half-screen window beside two quarter-screen windows.

[…]

But Task View does have one feature I desire in Mission Control: each PC thumbnail incorporates a little clickable “x” that allows me to close it then and there. This is handy when I want to shut down a bunch of apps and windows quickly. While Mission Control lets me switch among open apps, it doesn’t let me quit them with a mouse click.

[…]

Microsoft is offering one of the best standalone news apps I have ever seen. Also known simply as News, it’s a revamping of an earlier app I did not like as much. The new version is vastly improved in appearance and functionality.