On Jun 2, 4:17 pm, Carl Banks <[EMAIL PROTECTED]> wrote:
> On Jun 2, 6:39 pm, "Russ P." <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Jun 2, 3:04 pm, Carl Banks <[EMAIL PROTECTED]> wrote:
>
> > > On Jun 2, 4:50 pm, "Russ P." <[EMAIL PROTECTED]> wrote:
>
> > > > On Jun 2, 6:41 am, Carl Banks <[EMAIL PROTECTED]> wrote:
>
> > > > > You are not realizing that only useful(**) thing about data hiding is
> > > > > that some code has access to the data, other code does not. If you
> > > > > "hide" data equally from everyone it's just a useless spelling change.
>
> > > > I think you're missing the point.
>
> > > Well that's nice: you're accusing me of missing the point after having
> > > quoted something I wrote as if it represented by own views, even
> > > though I footnoted it and said I was only doing it for the sake of
> > > argument. Perhaps, outside this discussion, I am totally getting "the
> > > point".
>
> > > I can't tell, though, because I read your post twice and I have no
> > > idea what you consider "the point" to be.
> > > Best as I can tell you are claiming that data hiding isn't important,
> > > but then you go on to imply Python is blemished because it doesn't
> > > hide data. It really makes no sense: perhaps you can help us out by
> > > giving us an example of something that illustrates what you're saying?
>
> > I think I made my point abundantly clear. I said that rigorously
> > denied access to encapsulated data is not important, but a clear
> > specification of what is intended for the client and what is intended
> > for internal use *is* important. And an ugly naming convention for
> > variable and function names is not the best way to do it.
>
> Well let me tell you what's confusing me here: I can't figure out, if
> this is your standpoint, what issue you could have had with what I
> said. What specifically did you disagree with? What did I say that
> was wrong? It seems like we are more in agreement than not.
>
> > I suggest you ask yourself why C++, Java, Ada, and probably most other
> > "object-oriented" languages, have encapsulation or "data hiding." And
> > no, I am not claiming that *every* application written in Python needs
> > it, but certainly *some* could benefit from it.
>
> I know what it's there for, chief. That's exactly what I was saying
> to Antoon, and you took issue with it and claimed I was missing the
> point. What gives?
>
> Carl Banks
I thought you were saying that encapsulation or so-called "data
hiding" is worthless. If I misunderstood you, then I apologize. I
don't have time to go back and sort it all out.
Here's what I think Python should have. I think it should have a
keyword, something like "priv," to identify data or functions as
"private." As I said earlier, "private" for class data or functions
("methods") could be implemented like "protected" in C++. That means
that derived classes would have access to it, but clients of the class
would not. If the client really needs or wants access, he could be
given a sort of "back door" access similar to the current Python rule
regarding double leading underscores. Thus, the client would have
access, but he would know very well that he is using something that
the original designer did not intend for him to use.
It's just a suggestion. I'm not a language expert, and I realize that
I could be missing something important.
I also realize, by the way, that Python allows a client of a class to
define a new class member from completely outside the class
definition. Obviously, that cannot be declared private. But if the
same identifier is already declared private within the class, than the
new definition should not be allowed (because it would defeat the
whole idea of "private" class members).
--
http://mail.python.org/mailman/listinfo/python-list
