On Jun 2, 7:41 pm, "Russ P." <[EMAIL PROTECTED]> wrote:
> 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.
No, not at all. I was suggesting that Antoon's example of data hiding
wasn't useful because it didn't really hide data: it was merely a
spelling change.
(I'm not, mind you, saying that it's ordinarily a good trade-off to
encapsulate data, but I do get the point of it.)
> 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.
Reasonable enough. I've always thought C++ should have a
private_cast.
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
