[swift-evolution] [Pitch] Changing NSObject dispatch behavior

[Freak Show]

> On Dec 29, 2016, at 16:34, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> By that measure there should be no encapsulation; we should make
> everything public, because somebody might need it someday.
> 

I don't know what you mean by "encapsulation" but I will explain what I think it means.

From Wikipedia https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)
In programming languages <https://en.wikipedia.org/wiki/Programming_languages>, encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination[1] <https://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29#cite_note-1>[2] <https://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29#cite_note-Dale-2> thereof:
A language mechanism for restricting direct access to some of the object <https://en.wikipedia.org/wiki/Object_(computer_science)>'s components.[3] <https://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29#cite_note-3>[4] <https://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29#cite_note-Pierce-4>
A language construct that facilitates the bundling of data with the methods <https://en.wikipedia.org/wiki/Method_(computer_programming)> (or other functions) operating on that data.[5] <https://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29#cite_note-5>[6] <https://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29#cite_note-6>

Objective C and Smalltalk have encapsulation.  iVars are always private.  Methods are always callable and "private implementation" is provided by convention (put private methods in private extensions/categories).  They do not have compiler enforced access control.

I'm not a fan of compiler enforced access control.  It has never helped me out but it has gotten in my way a number of times. There are plenty of ways to do information/implementation hiding without relying on the compiler to play nanny.   

My views on what I like in programming languages are largely informed by my years of doing C++, Smalltalk, Java, and Objective C (in that order). 

Two of those languages I found rigid, frustrating, and limited and I avoid working in them as much as possible.  Two of them I find malleable and expressive and seek out opportunities to work in them.

Which is which I leave as an exercise to the reader but the ones I prefer are NOT Java or C++ (although I'm fine with using C++ for limited sized high performance libraries like audio processing units).

Cheers,
-Todd Blanchard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161229/37361f6e/attachment.html>