commander Ты не прав, ООП в Перл, до версии 6, эмулируемый, о 6 не знаю.
Вот абзац из
http://www.manning.com/conway What object-oriented Perl isn’tPerl was not originally designed—or implemented—as an object-oriented language. Its version of
object orientation is simple and well integrated, but not fundamental to the language.1
------------------------------------
1 …as it is in Java, or Eiffel, or Python, for example.
------------------------------------
That evolutionary development shows in the few places where object-oriented features of the
language are still experimental or incomplete. For example, recent versions of the Perl compiler
support weakly typed variables, which provide compile-time checking and optimization for accesses
to the data stored in Perl objects. But the current version of the mechanism doesn’t actually
enforce type safety or proper data encapsulation, nor does it fully support inheritance.
Because Perl wasn’t originally designed as an object-oriented language, object-oriented Perl
isn’t fast. Calling a method through an object is significantly slower than calling a regular Perl subroutine.
Just how much slower is a matter of some debate, and depends on whether you measure
entire software systems or just raw single-call invocation speed.
A single method call is about 30 percent slower than a regular call to the same subroutine
(depending on your hardware, your operating system, the phase of the moon, etc.) But though
they’re individually much slower, method calls are more powerful than regular subroutine calls,
due to a feature known as polymorphism (see chapters 1 and 7). In a larger system, that redresses
the speed imbalance in a little, but, in general, it’s fair to say that an object-oriented implementation
of a system in Perl will almost never be faster than the equivalent non-object-oriented implementation,
and will usually be somewhere between 20 to 50 percent slower.
Those figures are enough to turn many people away from object-oriented Perl, and that’s a
pity because then they miss out on the many compensating benefits of object-oriented design and
implementation: simpler analysis methods, a domain-oriented approach to design, cleaner and
more compact code, more robust implementations, greater code modularity, easier debugging,
more comprehensible interfaces to modules (including operator-based interfaces), better abstraction
of software components, less namespace pollution, greater code reusability, scalability of software,
and better marketability of the final product.2
The sad thing is that people get spooked by the numbers (20 to 50 percent slower!!!) and forget
what that really means (…just as fast in six months time, when processor speeds have doubled).
