> On Dec 22, 2015, at 6:24 PM, Dave Abrahams <dabrah...@apple.com> wrote: > >> On Dec 22, 2015, at 9:03 AM, Paul Cantrell via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> I weigh the safety argument against the many long hours I’ve spent beating >> my head against library behaviors, wishing I could read UIKit’s source code, >> wishing I could tweak that one little thing that I can’t control, and being >> grateful for the dubious workaround that saves the day — yes, even when a >> subsequent OS update breaks it. I know what I’m getting into when I solve a >> problem with a hack, and if the hack ships, it’s only because I weighed the >> risks and benefits. We app developers rely on swizzling, dubious >> subclassing, and (especially) undocumented behavior far more often than any >> of us would like. It is just part of the reality of making things ship — and >> an important part of the success of Apple’s app ecosystem. > > The same argument implies that we never should have created Swift as it is; > that leaving everything dynamic everywhere is necessary so people can get > their work done. In some ways it’s a self-fulfilling prophecy. I once knew > a programmer that argued that all properties/ivars should be public, in case > you need to go in and work around some problem. Naturally, he “needed" to > take advantage of that public exposure all the time. I predict that, as > Swift does more to disallow unintended effects, you’ll start to see fewer and > fewer of the kinds of problem that require these dubious workarounds.
Well, coming from a “strong static types or bust” background, when I first worked with Ruby I was shocked at how the world did not fall apart even though everything is open to monkey patching! It’s definitely a different mindset — but one in which people exercise careful thought, and write good, reliable software. This stunned me when I first encountered that world, but it’s an empirical fact that it can work quite well. The ways in which it succeeds forced me to rethink a lot of how I approach code. That said, the “everything dynamic and rewirable” way is _clearly_ not the Swift way, and with “The same argument implies…,” you’re misreading my argument. In principle, I lean in favor of final by default. It’s clearly more consistent with Swift’s approach. I’m just pointing out that there will need to be something of a culture / ecosystem shift if the platform follows Swift’s lead toward more defensive programming and tighter control. The approaches that have been working for Objective-C library authors, including but not limited to Apple, will not continue to work as is. >> I’m not totally opposed to final by default. Joe’s arguments sway me in >> principle. In practice, if Swift does indeed moves us toward “less wiggle >> room, less hackable” by default, then that wiggle room _will_ have to come >> from somewhere else: perhaps more open sourcing and more forking, or faster >> turnaround on fixes from library authors, or a larger portion of time spent >> by library authors explicitly exposing and documenting customization points. >> The new effort involved for library authors is nothing to sneeze at. > > No, it’s nothing to sneeze at; it is essential for creating reliable > software. As a library author, I support anything that helps produce that > level of care :-) Yes: a high level of care, and also open communication, and faster turnaround, and good listening, and … well, exactly the sort of effort Apple is putting forth right now for Swift! Cheers, Paul _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
