usefulness of "data hiding"

usefulness of "data hiding"

[Russ P.]

Hello,

I thought some of you here might be interested in the following debate
I have been having on comp.lang.python with regard to the usefulness
of "data hiding" or "enforced encapsulation."

As many of you probably know, Python had no data hiding. It does not
allow you to declare anything "private," and everything is public by
default. (The convention is Python is to use a leading underscore to
identify a private _object or _function.) I suggested that a "private"
declaration could be useful if it could be implemented without
changing the language too drastically. Now, I can understand that
people just don't want to change the language that fundamentally, but
many Python folks over there insist that data hiding is just plain
useless in general. In fact, several people over there have argued
that Python is perfectly appropriate for even the largest safety-
critical systems.

I've tried to explain to them why data hiding can be useful, but I
just get back a lot of flak. If any of you are interested and have the
time to educate them, I'd be interested in your replies to the
following post, which was a reply to a post of mine. The link is

http://groups.google.com/group/comp.lang.python/browse_frm/thread/068bc54bca830c46?scoring=d&

Here is an excerpt:

The first OO languages (at least the second one - Smalltalk) used
data-hiding to clearly emphasize the "black box" nature of objects and
the use of messages as the main (only in the case of Smalltalk)
support
for control flow. Remember than by that time, lost of programs where
still mostly relying on *global* state changes. IOW, it has a strong
educative value then...

Following "OO" languages - mostly C++ and Java - kept this "rule" like
it was a sacred cow (but mostly forgot about the more important points
of 'everything is an object' and message-passing as main control
flow).
Then everyone started considering this as "fundamuntal", and here we
are
years later with one more cargo cult, when years of experience prove
that it's not - at least from a practical POV.

Once again, the important point is that there's a *clear* distinction
between interface and implementation, and that you *shouldn't* mess
with
implementation. But what, some people think programmers are stupid,
and
so they hire stupid programmers, so they need b&d languages to protect
stupid programmers from themselves - which just doesn't work, since
*nothing* is idiot-proof. Heck, how many Java "OO" programs with dumb
getter/setter pairs for _each and any_ attribute ?

> As I said before, enforced encapsulation may not be appropriate for
> every application, but it is definitely appropriate for some.

No. It is appropriate for dummy managers hiring dummy programmers. The
project's size and domain have nothing to do with it.

> Not
> every door needs a lock, but certainly some do.

You only need locks when you don't trust your neighbours.

Re: usefulness of "data hiding"

[Russ P.]

Well, I thought I had provided the link to the individual post, but
apparently the link was for the entire thread (which started out as a
different topic). This should be the correct link:

http://groups.google.com/group/comp.lang.python/tree/browse_frm/thread/068bc54bca830c46/a04f80497d973390?rnum=171&_done=%2Fgroup%2Fcomp.lang.python%2Fbrowse_frm%2Fthread%2F068bc54bca830c46%3Fscoring%3Dd%26&scoring=d#doc_21d8aa329dc1c536

By the way, my post should read, "Python has no data hiding," rather
than "Python had no data hiding."

Re: usefulness of "data hiding"

[Adam Beneschan]

On Jan 15, 4:51 pm, "Russ P." <Russ.Paie...@gmail.com> wrote:
> Hello,
>
> I thought some of you here might be interested in the following debate
> I have been having on comp.lang.python with regard to the usefulness
> of "data hiding" or "enforced encapsulation."
>
> As many of you probably know, Python had no data hiding. It does not
> allow you to declare anything "private," and everything is public by
> default. (The convention is Python is to use a leading underscore to
> identify a private _object or _function.) I suggested that a "private"
> declaration could be useful if it could be implemented without
> changing the language too drastically. Now, I can understand that
> people just don't want to change the language that fundamentally, but
> many Python folks over there insist that data hiding is just plain
> useless in general. In fact, several people over there have argued
> that Python is perfectly appropriate for even the largest safety-
> critical systems.

About the only thing I can say is in response to this (I'm assuming
the following quote is not your own):

> No. It is appropriate for dummy managers hiring dummy programmers. The
> project's size and domain have nothing to do with it.

I think that for this purpose, being capable of making a mistake makes
one a dummy programmer.  And that would include me, despite the fact
that I've been programming for over 30 years.   I do appreciate
language features to help make it more difficult for me to make a
mistake, because that cuts down on the amount of time I have to spend
debugging my mistakes.  Actually, I can't imagine why anyone wouldn't
appreciate that, although I suspect it's an ego thing.

                               -- Adam

Re: usefulness of "data hiding"

[Marc A. Criley]

Adam Beneschan wrote:

> I think that for this purpose, being capable of making a mistake makes
> one a dummy programmer.  And that would include me, despite the fact
> that I've been programming for over 30 years.   I do appreciate
> language features to help make it more difficult for me to make a
> mistake, because that cuts down on the amount of time I have to spend
> debugging my mistakes.  Actually, I can't imagine why anyone wouldn't
> appreciate that, although I suspect it's an ego thing.

Heh :-) See "Confessions of a Terrible Programmer"...

(http://blog.kickin-the-darkness.com/2007/09/confessions-of-terrible-programmer.html)

Marc A. Criley
McKae Technologies

Re: usefulness of "data hiding"

[Adam Beneschan]

On Jan 17, 11:05 am, "Marc A. Criley" <mcNOS...@mckae.com> wrote:
> Adam Beneschan wrote:
> > I think that for this purpose, being capable of making a mistake makes
> > one a dummy programmer.  And that would include me, despite the fact
> > that I've been programming for over 30 years.   I do appreciate
> > language features to help make it more difficult for me to make a
> > mistake, because that cuts down on the amount of time I have to spend
> > debugging my mistakes.  Actually, I can't imagine why anyone wouldn't
> > appreciate that, although I suspect it's an ego thing.
>
> Heh :-) See "Confessions of a Terrible Programmer"...
>
> (http://blog.kickin-the-darkness.com/2007/09/confessions-of-terrible-p...)

Wonderful...thanks!!!  Interestingly, I skimmed through the comments
and found someone suggesting that using Python will help you get to
"bug-free nirvana" more quickly.  I don't actually have any experience
with Python so I don't know why they think this might be the case...

                                 -- Adam

Re: usefulness of "data hiding"

[Dmitry A. Kazakov]

On Thu, 15 Jan 2009 16:51:38 -0800 (PST), Russ P. wrote:

> As many of you probably know, Python had no data hiding.

Python is a dynamically typed language. When dynamic typing is considered
conceptually that inevitably leads you to weak and then to no typing. In an
effectively untyped framework (this includes massive type inference as
well), you necessarily have to drop encapsulation. There is nothing to
hide, and nothing can be hidden.

The problem is that languages like Ada, which are supposed to represent an
alternative, lag behind in developing their type systems. In Ada you
trivially cannot abstract a record type member, or cannot declare an
abstract  type to serve as a discrete index of an array, etc. So hiding
does not work there as it could and should. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: usefulness of "data hiding"

[sjw]

On Jan 16, 8:57 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 15 Jan 2009 16:51:38 -0800 (PST), Russ P. wrote:
> > As many of you probably know, Python had no data hiding.
>
> Python is a dynamically typed language. When dynamic typing is considered
> conceptually that inevitably leads you to weak and then to no typing. In an
> effectively untyped framework (this includes massive type inference as
> well), you necessarily have to drop encapsulation. There is nothing to
> hide, and nothing can be hidden.

I have seen it said (maybe about Python) that that sort of language
has untyped variables but strongly typed values in that the value
knows what it is and what can be done to (by) it.

Of course you can't tell whether o.lower() will return the lower-case
version of the string o or the tune o transposed down by a semitone or
a runtime error, which does make it kind of hard to reason about the
program; but I don't see where that equates to dropping encapsulation.

Re: usefulness of "data hiding"

[Dmitry A. Kazakov]

On Fri, 16 Jan 2009 15:23:10 -0800 (PST), sjw wrote:

> On Jan 16, 8:57�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Thu, 15 Jan 2009 16:51:38 -0800 (PST), Russ P. wrote:
>>> As many of you probably know, Python had no data hiding.
>>
>> Python is a dynamically typed language. When dynamic typing is considered
>> conceptually that inevitably leads you to weak and then to no typing. In an
>> effectively untyped framework (this includes massive type inference as
>> well), you necessarily have to drop encapsulation. There is nothing to
>> hide, and nothing can be hidden.
> 
> I have seen it said (maybe about Python) that that sort of language
> has untyped variables but strongly typed values in that the value
> knows what it is and what can be done to (by) it.

But you don't deal with values (more precisely objects) in the program. You 
do with the variables denoting objects or expressions constructing objects 
etc. When these are effectively untyped, then the language is, per use. I 
include here the case when "everything is Object."

> Of course you can't tell whether o.lower() will return the lower-case
> version of the string o or the tune o transposed down by a semitone or
> a runtime error, which does make it kind of hard to reason about the
> program; but I don't see where that equates to dropping encapsulation.

That is because types as sets of values sharing some operations do not 
vanish. They still exist, all people use this abstraction when programming 
already at minimal level of reusability [*]. Even if the language does not 
spell types properly, it has some substitute for types and their algebra. 
If the language does not use nominal typing like in Ada, then it does 
structural one and/or type inference. My point was, that when you go for 
structural /inferred typing, you have to lose at least some encapsulation.

------
* When you write code to be used by another programmer

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: usefulness of "data hiding"

[Graham Stark]

On Jan 16, 8:57 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 15 Jan 2009 16:51:38 -0800 (PST), Russ P. wrote:
> > As many of you probably know, Python had no data hiding.
>
> Python is a dynamically typed language. When dynamic typing is considered
> conceptually that inevitably leads you to weak and then to no typing. In an
> effectively untyped framework (this includes massive type inference as
> well), you necessarily have to drop encapsulation. There is nothing to
> hide, and nothing can be hidden.
>

There's not much relationship between weak typing and data hiding, is
there?

The least strongly typed language I know of is PHP
($s = "x" + 10; is legal, for instance)
but you can have complete encapsulation if you want it:

class A{
    private $a;
    function getA(){ return $this->a; }
    function setA( $a ){ $this->a = $a; }
}

and there are strongly typed languages, like Pascal, where you can't
do this at all.

Graham

 > Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

Re: usefulness of "data hiding"

[Dmitry A. Kazakov]

On Sun, 18 Jan 2009 05:07:40 -0800 (PST), Graham Stark wrote:

> On Jan 16, 8:57�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Thu, 15 Jan 2009 16:51:38 -0800 (PST), Russ P. wrote:
>>> As many of you probably know, Python had no data hiding.
>>
>> Python is a dynamically typed language. When dynamic typing is considered
>> conceptually that inevitably leads you to weak and then to no typing. In an
>> effectively untyped framework (this includes massive type inference as
>> well), you necessarily have to drop encapsulation. There is nothing to
>> hide, and nothing can be hidden.
> 
> There's not much relationship between weak typing and data hiding, is
> there?
> 
> The least strongly typed language I know of is PHP
> ($s = "x" + 10; is legal, for instance)
> but you can have complete encapsulation if you want it:
> 
> class A{
>     private $a;
>     function getA(){ return $this->a; }
>     function setA( $a ){ $this->a = $a; }
> }
> 
> and there are strongly typed languages, like Pascal, where you can't
> do this at all.

In order to reason about these examples, you should tell me what was
dynamic and encapsulated in the examples you provided. I don't know PHP,
but "x" and 10 look like literals. That does not sound like dynamic typing. 

Again, I don't know PHP, but considering Ada's:

   type A is private;
private
   type A is new Integer;

Here the operation "+" of A is hidden. In a dynamically typed language you
cannot do it, the interface of any type has all possible operations. you
possibly can override implementations, but you cannot remove them. I don't
know what PHP would bind public "+" to in a comparable case. Would it be to
"method-not-understood" or to the original "+". Any choice breaks
encapsulation to me.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: usefulness of "data hiding"

[Nicholas Collin Paul Gloucester]

On 2009-01-16, Russ P. <Russ.Paielli@gmail.com> wrote:

|----------------------------------------------------------------------|
|"Hello,"                                                              |
|----------------------------------------------------------------------|

Hi,

It has been a long time since I seemed to notice a post from you here.

|----------------------------------------------------------------------|
|"[..]                                                                 |
|                                                                      |
|I've tried to explain to them why data hiding can be useful, but I    |
|just get back a lot of flak. If any of you are interested and have the|
|time to educate them, I'd be interested in your replies to the        |
|following post, which was a reply to a post of mine. The link is      |
|                                                                      |
|http://groups.google.com/[..]                                         |
|                                                                      |
|Here is an excerpt:                                                   |
|                                                                      |
|[..]                                                                  |
|                                                                      |
|[..]                                                                  |
|*nothing* is idiot-proof."                                            |
|----------------------------------------------------------------------|

He has got you there.

|----------------------------------------------------------------------|
|" Heck, how many Java "OO" programs with dumb                         |
|getter/setter pairs for _each and any_ attribute ?"                   |
|----------------------------------------------------------------------|

Ditto.

|----------------------------------------------------------------------|
|"> As I said before, enforced encapsulation may not be appropriate for|
|> every application, but it is definitely appropriate for some.       |
|                                                                      |
|No. It is appropriate for dummy managers hiring dummy programmers. The|
|project's size and domain have nothing to do with it.                 |
|                                                                      |
|> Not                                                                 |
|> every door needs a lock, but certainly some do.                     |
|                                                                      |
|You only need locks when you don't trust your neighbours."            |
|----------------------------------------------------------------------|

Russ, it may be too hard to get through that machoist Python programmer's skull.

Good luck trying anyway,
Colin Paul Gloster