7.5.1 Tcl

The base Tcl library does not have any object-oriented features. It has recently acquired a package construct that provides a namespace for subroutines and global variables (there is no relationship between packages). Tcl is a very malleable language, and several freely available libraries strive to impose an object-oriented structure on the language. A package called stoop provides a pure Tcl solution featuring single and multiple inheritance, dynamic binding, run-time type identification, and so on. Another, called [ incr Tcl] , is a slightly more ambitious effort and provides a C++-like set of keywords and facilities. incr Tcl requires a patch to Tcl, though.

7.5.2 Python

Python is an excellent language for learning object orientation. (It also happens to be my favorite OO scripting language.) All facilities, including internal data structures such as lists and dictionaries (hash tables) and external libraries have consistent object-oriented interfaces. Python provides a number of hooks for class developers to write different types of accessor methods and supports multiple inheritance. All objects in Python are implemented as hash tables, unlike in Perl, in which you have to choose a representation (or looking at it more optimistically, where you are free to choose the optimal representation).

7.5.3 C++ and Java

There are a number of significant differences between Perl and C++ in their approach to object-orientation.

• Object structure . C++ requires you to declare your object's structure using the class keyword, unlike Perl, which doesn't care how you keep your object's state - as a hash, array, or scalar. The only thing Perl really asks is that you return a blessed reference to that data.

• Privacy . C++ has keywords to enforce various shades of privacy ( private , protected , public ). Perl does not enforce privacy; if you need privacy you can use lexical variables.

• Constructors/destructors . C++ requires that the constructing subroutine of an object have the same name as the class. Perl doesn't have any such strictures - any subroutine can be a constructor (the name new is just a convention). On the other hand, when an object is going to be destroyed, both Perl and C++ require well-known destructor names. A C++ constructor is really an initializer; the memory is allocated before the constructor is given control. In Perl, it is the programmer's responsibility to do both allocation and initialization.

• Static versus instance methods . C++ provides the static keyword to distinguish between static functions and object methods. Perl doesn't make that distinction - subroutines are indistinguishable from each other. A Perl subroutine can examine its arguments and can act as either.

• Declaration and definition . C++, unlike Perl, requires that declaration of a class be independent of its implementation (unless the implementation is inline). The typical C++ convention is to put the declarations in a header file and the implementation in a separate file.

• Compile-time versus run-time features . C++ requires that all class information, such as the inheritance hierarchy, the number and type of attributes and methods, and so on, be known at compile-time. Perl allows a run-time redefinition of everything; you can add, delete, or update methods or change the inheritance hierarchy by changing @ISA . I recommend that you not take advantage of this ability.

• Run-time binding . Since C++ does strict type-checking, run-time binding works only if the objects inherit from a common base class. Perl doesn't have this restriction.

Much of what has been said of C++ in the above comparison is true of Java too.