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:<br><br>- consistent APIs<br>- consistent implementations<br><br>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). <br><br>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.<br><br>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.<br><br>--<br>Ilya Belenkiy<br><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 14, 2015 at 9:02 AM Brent Royal-Gordon <<a href="mailto:brent@architechies.com">brent@architechies.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Do you really see no value in completely hiding implementation details of an API and making it enforceable by the compiler?<br>
<br>
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`.<br>
<br>
I’ve seen you make this argument several times:<br>
<br>
> If you were writing a book, would you want to put every paragraph into a separate file?<br>
<br>
<br>
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.<br>
<br>
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?<br>
<br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
</blockquote></div>