[swift-evolution] [Review] SE-0159: Fix Private Access Levels (undermining my own case)

[Matt Gallagher]

Without retracting any of the statements I made in my previous message:

	https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034336.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034336.html>

I'd like to point out that on a 1 to 10 scale of Swift past and potential changes that I'm passionate about – with a perfect 10 reserved for the Swift Ownership Manifesto and a 1 being something trivial like SE-0106 (Add a macOS Alias for the OSX Platform) – this issue rates around a 3 for me. I care but not a lot.

I'm mentioning this because a number of people on Twitter are commenting that discussion on this issue has gotten a little quarrelsome and I'm sorry if I've had a part in that. I only weighed-in to state that I have an opinion, not to draw a line in the sand and dig a bunker.

I'm fully aware that scoped access modifiers are basically an issue of aesthetics; allowing you to keep two entities that need interface-hiding in the same file, rather than in separate files. On that point, the whole issue could be seen as bike-shedding.

Further, even for my own "primary use case" that I personally gave here:

	https://gist.github.com/mattgallagher/b93c6e587488d60a68e4cc0318a7c356 <https://gist.github.com/mattgallagher/b93c6e587488d60a68e4cc0318a7c356>

I can think of additional abstractions that would make the `private` members inaccessible while still keeping both View-Model and View-Binding in the same file e.g.

	a) Wrapping the `input` and `output` members in a generic wrapper that lives in another file (and so can take advantage of interface-hiding between files) and handles the required input-hidden/managed, output-exposed pattern

	b) Building a series of libdispatch/reactive/whatever closures up in the `init` method that contain and self-manage the internallyMaintainedState – so it doesn't need to reside the View-Model at all – and merely store an opaque KeepAlive instance in the View-Model to anchor the lifetime

Involving more abstractions like this or setting up an opaque, self-managing entities does mean more work – both implementation time and conceptual gymnastics – but these approaches could deliver similar aesthetics without needing scoped access modifiers. There are potential performance implications involved in adding abstractions and closures but these can be handled as they arise.

Regards,
Matt Gallagher.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170325/0687fb44/attachment.html>