> On Dec 29, 2016, at 16:34, Dave Abrahams via swift-evolution
> <swift-evolution@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
