There can be levels of encapsulation. And this may not be a good thing. Acording to Stroustrup in C++ there is one too many. In The design and evolution of C++ page 302 he says In retrospect, I think that protect is a case where "good arguments" and fashion overcame my better judgement and my rules of thumb for accepting new features. Admittedly in Perl there is no level of encapsulation. Object variable members are accessible to anyone but people cannot access one by mistake unlike C++ because in Perl one must explicitly mention the object when accessible a member variable $self->{var}. Perl6 will probably be hoepfully less verbose while still avoiding the C++ potnetial ambiguity: $.var (note the dot that means that a member variable is accessed). In C++, in a member method, you can access by mistake a member variable of the class or a parent class when you thought you were accessing a global variable or if you forgot to declare the lexical variable you use.

Also there is two kinds of encapsulation: forced or not. In perl no one is ever forced to anything. As I said before, there is encapsulation in the sense that no one can unwillingly access object data.

BTW: C++ forced encapsulation is a joke because it is so easy to defeat. It is just a compilation thing, no check at link time:

#define private public
#define protected public
#define class  struct
[download]

Anyway, one must always be careful of language comparaison because one always uses the metric adapted for its favorite language. Judging a language only for its OO-ness is a very restricted view in my opinion.

In fact pure OO language are insanely verbose for the "Hello World" test. One of the perl feat is to scale from oneliners to moderately big programs. In this case, good score in the "pure OO-ness" metric is a _bad_ thing.

Corrected the Stroustrup reference

-- stefp -- check out TeXmacs wiki

C++ private/public is checked at link time. If you compile the code as private, then change the header to read public and compile a client of the class, the problem will be caught at link time because the attributes are encoded in the name.

If you defeat that, it might not work at all because the ordering may change in the layout of the data or virtual functions!

This must be platform dependant because on my linux box with g++ 3.2. I get to link and execute.

John M. Dlugosz. Are you sure of what you say? Sorry about the off topic. ==toto.h

class A {
  int ma;

  void printit();

  A::A() : ma(666) {}
};
[download]

==toto1.cc

#include "iostream"
#define class struct
#include "toto.h"

main() {
  A a;
  std::cerr << a.ma << "\n";
  a.printit();
}
[download]

==toto2.cc

#include "iostream"
#include "toto.h"

void
A::printit() {
  std::cerr << ma << "\n";
}
[download]

===Compilation, link, execution

$ g++ -c toto1.cc -o toto1.o
$ g++ -c toto2.cc -o toto2.o
In file included from toto2.cc:2:
toto.h:1: warning: all member functions in class `A' are private
$ g++ toto*.o -o a.out
$ ./a.out
666
666
$
[download]

I suppose it's implementation-dependant as to whether this is actually checked. I suppose it's a tradeoff on whether you fail to link if you change the protection but "handle" overloading based on protection! I recall at least one compiler that checked, but it may be because it was more aggressive at optimizing and rearranging things.

For a virtual function, re-ordering the definitions will indeed change things on any known compiler.

Perl has a complete set of typical OO-operations available, as long as everyone cooperates.

-- Randal L. Schwartz, Perl hacker

I am speaking of Perl's OO encapsulation being weak, and it is. Yes you can acheive various degrees of encapsulation, but at a cost (or in Damian's words, by turning Perl's flexibility against itself). I think saying that Perl's OO encapsulation is 'weak at best' is a fair statement.

You keep using the phrase "weak at best". I do not think it means what you think it means.

Feel free to explain how an enclosed lexical is "weakly" encapsulated. It may not be the most popular way of creating an object property, but it is a deliberate language feature.

It isn't weak, it's flexible. It's that simple. You can encapsulate as strongly as you wish. It isn't even all that costly. Bottom line, the language scales, from oneliners to 2,500,000 projects. You pick from the possibilities whatever your current task necessitates. Most people, most of the time, write stuff somewhere close to the oneliner end of the range. Perl's default behaviour is therefor only sensible.

Makeshifts last the longest.

Is that can in the same vein as "you can write structured if/while/etc code in assembly language."?

Perl can do a great deal. I think the question is arguing semantics on how much innate support is required to be an OO language.

My design is object-oriented. It's implemented in Perl. QED?

—John