Re: back to: improving rpg. was: what is object oriented programming -- RPG400-L

Joe Pluta wrote:

Hans, this just isn't correct.  Without objects, you don't have data
members, so the issue of setters and getters just doesn't come up.  The
closest you can come is static procedure variables, which are really quite
different since a single process can't have two "objects" with different
values in the static procedure variable.

Having private data members, on the other hand, is absolutely an OO concept,
dating back as far as Simula, the first OO language, and Smalltalk, the most
OO language of all.  C++, Java and Eiffel Ada all support them.  Smalltalk
doesn't necessarily even have private methods or classes, but it still has
private variables.  And it's not an issue of compiled vs. interpreted
languages; even JavaScript and Perl support private variables (though Perl
requires a little more work).

The primary motivation of creating abstract data types (or classes) is that
global variables are a bad thing.  Thus, every OO language has the concept
of a private variable.  Not "certain" languages.  Every OO language besides
Python.

The fact that Python doesn't support private variables doesn't make them
non-OO, it makes Python different.

But Joe, the fact that a language supports objects does not make it an "object-oriented" language. (Just like the fact that OS/400 has "objects" doesn't make it "object-oriented".) In any old procedural language, you can support a framework where "objects" are created and referred to using pointers and where the hidden attributes of the objects are "get" and "set" using procedures.

Regarding Python, it does indeed support private attributes. Names beginning with two underscores are considered "private" to the class and aren't made public when a class is imported. Furthermore, attributes (rather than functions) can be handled as read-only or write-only by appropriate coding of the "__getattr__" and "__setattr__" methods. (This latter feature makes "get" and "set" methods somewhat unnecessary.)

My point, though, is simply that even if a language doesn't enforce privacy of attributes, the principle of data hiding can still be implemented using coding conventions. In other words, if a programmer is disciplined enough to stick with specific design patterns, he is certainly quite able to follow privacy conventions established for the classes.

Looking at the issue from another angle, consider C++. You can get around data hiding by coding a hack like "#define private public", making a mockery of the strict compile-time checking. In that case, you still have to depend on the programmer doing the right thing anyways.

In conclusion, the ability to implement data hiding in some form or other may well be a characteristic of good OO programming (no argument there). But the strict enforcing of data hiding by the language processor is not necessarily a requirement of an OO language, nor is the principle of data hiding exclusive to OO.

Cheers! Hans