Timeline for Why have private fields, isn't protected enough?
Current License: CC BY-SA 4.0
52 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| S Apr 7, 2021 at 6:45 | history | suggested | Utku | CC BY-SA 4.0 | Clarify meaning |
| Apr 4, 2021 at 21:50 | review | Suggested edits | |||
| S Apr 7, 2021 at 6:45 | |||||
| Mar 20, 2016 at 14:16 | comment | added | Wayne Werner | Python's convention is "we're all consenting adults here". I can honestly say that I've never been in a situation where I've thought, "Boy, I'm so glad they made that variable private!" On the other hand I've had several instances where a developer decided that a variable should be private because information hiding!!11!1! And my life was made more difficult. | |
| Mar 18, 2016 at 14:37 | comment | added | GordonM | Shouldn't it be "Private by community"? :) | |
| Mar 18, 2016 at 10:12 | answer | added | Arnab Datta | timeline score: -1 | |
| Mar 17, 2016 at 5:52 | history | tweeted | twitter.com/StackProgrammer/status/710342979664351232 | ||
| Mar 16, 2016 at 13:24 | comment | added | sara | "In OOP, sooner or later, you are going to make a subclass of a class and in that case, it is good to understand and being able to modify the implementation completely." there's a whole truck-load of assumptions here, and I don't agree with either of them. why do you think this? | |
| Mar 16, 2016 at 13:17 | comment | added | Marian Spanik | You can make any protected method be "public" by inheriting the class and in the child make a public method which calls the protected method of its parent. | |
| Mar 15, 2016 at 10:38 | history | edited | Adam Libuša | CC BY-SA 3.0 | Highlighting of computer-related terms |
| Mar 14, 2016 at 22:03 | comment | added | jpmc26 | Also related: stackoverflow.com/q/18168410/1394393 | |
| Mar 14, 2016 at 18:46 | comment | added | imel96 | don't remove this please... steve-yegge.blogspot.com.au/2010/07/… | |
| Mar 14, 2016 at 10:27 | answer | added | imel96 | timeline score: 1 | |
| Mar 14, 2016 at 4:29 | answer | added | Jay | timeline score: 1 | |
| Mar 13, 2016 at 19:31 | answer | added | Phil Lello | timeline score: 0 | |
| Mar 13, 2016 at 18:59 | vote | accept | Adam Libuša | ||
| Mar 12, 2016 at 15:58 | answer | added | Jules | timeline score: 1 | |
| Mar 12, 2016 at 12:08 | answer | added | gnasher729 | timeline score: -1 | |
| Mar 11, 2016 at 23:50 | answer | added | Murphy | timeline score: 3 | |
| Mar 11, 2016 at 23:02 | comment | added | abluejelly | @jpmc26 Couldda sworn there was a man or help or something that just printed the __doc__, but failed on hidden. But I very well might be thinking from x import *. Was a long time ago that I messed with python. | |
| S Mar 11, 2016 at 22:55 | answer | added | J_mie6 | timeline score: 0 | |
| S Mar 11, 2016 at 22:55 | history | protected | CommunityBot | ||
| Mar 11, 2016 at 22:51 | answer | added | Pace | timeline score: 4 | |
| Mar 11, 2016 at 22:43 | comment | added | jpmc26 | @abluejelly Yes, single underscore, double underscore in front for name mangling, double underscore in front and at the end for magic methods. It depends on how you look. If you do dir(o) on anything, you'll get everything (even the name mangled attributes and magic methods). I think you're thinking of from x import * statements, which don't import attributes on the module starting with an underscore. | |
| Mar 11, 2016 at 22:38 | comment | added | abluejelly | @jpmc26 Actually another note with that, it doesn't really warn it so much as Python will not help the coder discover/access/understand any member that starts with.... One underscore? It's been a while. | |
| Mar 11, 2016 at 22:26 | comment | added | jpmc26 | It might interest you to learn that Python doesn't have a concept of private or protected. There is a naming convention for warning callers of your code not to mess with stuff, but there's no actual prevention. This sounds insane if you are coming from a language like Java or C# that does have these and encourages you to use them, but if you give it a chance, you'll find that it's not really that big a deal. Note that this doesn't mean that Python programmers recommend leveraging this fact in normal situations. It just means you need to know what is a good idea and what's stupid. | |
| Mar 11, 2016 at 21:42 | comment | added | abluejelly | @CaptainMan C# protected implies only accessible to the class and its descendants. Swift doesn't have a protected, but its internal behaves like the protected you describe. If you wanna read Apple's devblog on it, it actually makes a pretty good case for both why they called it internal and why the inheritance-based protected is pretty meh | |
| Mar 11, 2016 at 21:33 | answer | added | supercat | timeline score: 4 | |
| Mar 11, 2016 at 20:33 | comment | added | Captain Man | Does protected in general imply it is also visible to the package, or is this only a Java thing? | |
| Mar 11, 2016 at 20:24 | answer | added | Alexey Vesnin | timeline score: -2 | |
| Mar 11, 2016 at 18:52 | comment | added | SáT | My professor used to say that "There are things I wouldn't tell my children. Those I my private fields." | |
| Mar 11, 2016 at 18:19 | comment | added | radarbob | I see many comments in our code: "// need to make this protected because ...". And I've had change to protected often enough. However, if we (and y'all out there!) simply had better classes - really sticking the Single Responsibility Principle - then other mechanisms and design patterns could more effectively address extendability issues. | |
| Mar 11, 2016 at 16:35 | comment | added | Mark Rogers | Encapsulation means you have to use less brain ram when you develop. | |
| Mar 11, 2016 at 13:47 | answer | added | JimmyB | timeline score: -1 | |
| Mar 11, 2016 at 13:15 | comment | added | Ian | I have voted to close as too board, as this can not be answers in a way that makes sense for ALL object oriented languages. | |
| Mar 11, 2016 at 13:04 | answer | added | flamingpenguin | timeline score: 13 | |
| Mar 11, 2016 at 13:00 | comment | added | Jens Schauder | "sooner or later, you are going to make a subclass of a class and in that case" - Ähm ... no. | |
| Mar 11, 2016 at 11:49 | comment | added | berry120 | Don't forget that protected doesn't always mean access is locked to the inheritance hierarchy. In Java, it grants package level access also. | |
| Mar 11, 2016 at 10:40 | comment | added | CodesInChaos | Derived classes are part of the outer world. | |
| Mar 11, 2016 at 10:09 | history | edited | Adam Libuša | CC BY-SA 3.0 | Better formulation |
| Mar 11, 2016 at 10:06 | answer | added | Ben Cottrell | timeline score: 9 | |
| Mar 11, 2016 at 9:51 | history | edited | Adam Libuša | CC BY-SA 3.0 | a dot |
| Mar 11, 2016 at 9:51 | comment | added | Ixrec | To downvoters: While I also strongly disagree with the OP's premises, I am upvoting this question because it is perfectly coherent and worth answering. Yes, the OP needs to be told why this is wrong, but the way to do that is to write an answer (or suggest edits to existing answers), not to downvote just because he hasn't figured it out for himself yet. | |
| Mar 11, 2016 at 9:50 | history | edited | Adam Libuša | CC BY-SA 3.0 | a dot |
| Mar 11, 2016 at 9:45 | history | edited | gnat | CC BY-SA 3.0 | added 2 characters in body; edited tags |
| Mar 11, 2016 at 9:44 | answer | added | Robbie Dee | timeline score: 35 | |
| Mar 11, 2016 at 9:37 | review | Close votes | |||
| Mar 12, 2016 at 11:30 | |||||
| Mar 11, 2016 at 9:34 | answer | added | Sebastian Redl | timeline score: 260 | |
| Mar 11, 2016 at 9:30 | answer | added | Ixrec | timeline score: 235 | |
| Mar 11, 2016 at 9:21 | comment | added | gnat | Possible duplicate of Why is Clean Code suggesting avoiding protected variables? | |
| Mar 11, 2016 at 9:20 | review | First posts | |||
| Mar 16, 2016 at 7:23 | |||||
| Mar 11, 2016 at 9:19 | history | edited | gnat | CC BY-SA 3.0 | redundant tag removed from title |
| Mar 11, 2016 at 9:17 | history | asked | Adam Libuša | CC BY-SA 3.0 |