[swift-evolution] access control proposal

[Ilya Belenkiy]

I am not going to run out of space, but I'd rather not have 10000000 files.
Also, i think that concern is too abstract to be useful. Implementation
details that are hidden by a public API is much more concrete. And as soon
as it is stated that way, there is often a lot of value in grouping related
APIs and implementations into one file:

- consistent APIs
- consistent implementations

For example, it may make sense to put all array based implementations of
data structures into one file or put related data structures in one file
(or both).

The language shouldn't dictate how to organize code. The existing solution
is great for modules and libraries, but it doesn't work well at the level
of a specific API.

The analogy of an encyclopedia can work in favor of local. If you look at
Wikipedia, it doesn't put every section of an article into a separate page.
It's all in one place.

--
Ilya Belenkiy

On Mon, Dec 14, 2015 at 9:02 AM Brent Royal-Gordon <brent at architechies.com>
wrote:

> > Do you really see no value in completely hiding implementation details
> of an API and making it enforceable by the compiler?
>
> On the contrary, I see great value in hiding implementation details. But,
> as I’ve previously explained, I don’t think adding a slew of different
> levels of access is the answer here. In many cases where `local` appears to
> be valuable, the real problem is that several concerns are being mixed
> together. That’s what’s wrong in the _queue/_children case: the concern of
> synchronizing access to _children has been improperly mixed with the
> concern of actually manipulating the _children array. Only by properly
> separating those concerns can you actually prevent bugs when accessing
> _children—and that separation is easily achieved with a separate file and
> `private`.
>
> I’ve seen you make this argument several times:
>
> > If you were writing a book, would you want to put every paragraph into a
> separate file?
>
>
> But that’s not what we’re actually contemplating here. A software project
> is a bit like an encyclopedia. Each article covers one subject, and not all
> subjects are the same. Some articles are short; some are long. But you
> would never glom several short articles together if they were about
> different subjects.
>
> Similarly, each file in a project should handle one concern. And it is
> concerns—not types, not scopes—which have implementation details that
> should be hidden from the outside world. Almost by definition, if there’s
> something in one part of a file that shouldn’t be accessed by another part,
> those two don’t belong in the same file. It doesn’t matter if some of the
> resulting files are only ten lines—you’re not going to run out of inode
> numbers, are you?
>
> --
> Brent Royal-Gordon
> Architechies
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151214/c218513c/attachment.html>