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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
