<div><div dir="auto">To give credit where due, I finally recalled where I had come across that particular reference to encapsulation. Chapter 1.3, <div><a href="https://github.com/hmemcpy/milewski-ctfp-pdf">https://github.com/hmemcpy/milewski-ctfp-pdf</a>.</div></div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 10, 2019 at 19:40 Dennis Raddle <<a href="mailto:dennis.raddle@gmail.com">dennis.raddle@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Indeed, Python does not enforce encapsulation. It has weakly enforced types as well (duck typing for most objects). But it's still an opportunity to follow an "encapsulation" convention and explain the purpose, while telling my student he won't see the full OO implementation until he gets into Java or C++. <br></div><div><br></div><div>I want to comment on Ramnath's point that encapsulation helps us hold fewer things in our minds. I would agree that's part of it, but in a general sense programming always involves more than we can hold in our minds and never requires us to hold all of it at once. <br></div><div><br></div><div>Consider a mathematical proof that runs to 300 pages. We don't need to hold the whole thing in our minds to create and understand it--but it's still worth finding a way to simplify it so it takes fewer pages or less advanced math. <br></div><div><br></div><div>Although we rarely prove a program's correctness in a strict sense, we probably give some thought to a rough justification of the correctness of our design choices, even if such a justification requires more thoughts than we can hold at once. There is a benefit in encapsulating so that the justification requires fewer thoughts -- say 20 thoughts instead of 200 thoughts.</div><div><br></div><div>Now, I'm not sure this is any closer to the heart of the matter. Maybe Ramnath is more essentially correct. Comments welcome.</div></div><div dir="ltr"><div><br></div><div>D<br></div><div><br></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 10, 2019 at 7:23 PM Richard O'Keefe <<a href="mailto:raoknz@gmail.com" target="_blank">raoknz@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Serious question: does Python _have_ encapsulation?</div><div class="gmail_default" style="font-family:monospace,monospace">I know about the single-underscore convention and</div><div class="gmail_default" style="font-family:monospace,monospace">the double-underscore convention, but even double-</div><div class="gmail_default" style="font-family:monospace,monospace">underscore attributes and methods can be accessed</div><div class="gmail_default" style="font-family:monospace,monospace">freely from the outside if you use the class-name</div><div class="gmail_default" style="font-family:monospace,monospace">prefix.  That is, it makes it difficult to breach</div><div class="gmail_default" style="font-family:monospace,monospace">encapsulation by accident, but it doesn't take the</div><div class="gmail_default" style="font-family:monospace,monospace">Lock-Picking Lawyer from YouTube to breach</div><div class="gmail_default" style="font-family:monospace,monospace">encapsulation on purpose without breaking stride.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 11 Mar 2019 at 09:29, Dennis Raddle <<a href="mailto:dennis.raddle@gmail.com" target="_blank">dennis.raddle@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I have a thought about OO vs. functional programming .<br></div><div><br></div><div>I'm moderately experienced with functional languages such as Haskell and Purescript and have used OO for many years at work (Python, C++).</div><div><br></div><div>I'm giving tutoring lessons in Python to a professional who wants to use programming as part of his work. (He's an entrepreneur.) He is eager to understand functional and OO styles within Python--he keeps asking about the real benefit of each, not content with a superficial approach.<br></div><div><br></div><div>I've explained about "encapsulation": gathering related functions together and minimizing coupling to the rest of the program. <br></div><div><br></div><div>He asks "why do we encapsulate?" I've explained that one reason is to help we, the programmers, be confident that our code is correct. <br></div><div><br></div><div>For example, in a class we try to isolate the implementation details from the rest of the program, and the compiler helps enforce that.So when we're writing our code and confirming to ourselves it's correct, we can make simplifying assumptions. We know the rest of the program won't modify our private variables and won't access us in any way other than the interface we've presented to the world.</div><div><br></div><div>I explained that a large program is like a corporation, and pieces of the program are like individual employees. When we write a class or function, in a sense we "become" that employee and "forget about" a lot of the details of other employees. (i.e., encapsulation). <br></div><div><br></div><div>Then has asked why functional programming is helpful. I explained about referential transparency. Say we're a function: then other "employees" (other functions) can trust us with simplifying assumptions, like no side-effects.</div><div><br></div><div>Then this thought occurred to me, which is nifty but maybe not the whole story.</div><div><br></div><div><br></div><div>"""<br></div><div>Say we're a class. Then the simplifying assumptions of OO allow *us* to trust the *rest of the program* won't mess with us.</div><div><br></div><div>Say we're a function. Then the simplifying assumptions of functional style help the *rest of the program* trust that *we* won't mess with it.<br></div><div>"""</div><div><br></div><div>D<br></div><div><br></div></div>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>
</blockquote></div>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Ramnath R Iyer</div></div></div>