On 1/19/06, Rob Kinyon <[EMAIL PROTECTED]> wrote:
> OOP is all about black-box abstraction. To that end, three items have
> been identified as being mostly necessary to achieve that:
>     1) Polymorphism - aka Liskov substitutability
>     2) Inheritance - aka specialization
>     3) Encapsulation
> P5 excels at #1, does #2 ok, and fails completely at #3.

If you're a purist, paranoid "nobody better touch my code, ever"
mindset[1], then you're right, Perl 5 fails at encapsulation. 
However, you could also say that Java fails at encapsulation because
it provides reflection, C++ fails at encapsulation because it allows
direct memory access, leaving only Eiffel which doesn't fail at
encapsualtion because its designers were paraniod idiologues :-p.

Perl the language, like a natural language, is interwoven with its
culture.  Perl does not fail at encapsulation when you consider the
cultural mores that one shouldn't touch the inside of an object and
that one shouldn't rebless an object.  Saying that Perl 5 has no
encapsulation means that you break these mores on a regular basis, and
deserve to be punished by society :-)

> Javascript is a good example of this. Yet, even in JS, you have the
> "prototype", which is the "class".

Perl 5's "class" is the package and the body of "new".


[1] Which I argue is not a productive mindset in all cases.  Sure, it
works most of the time.  Most of the time it ends up creating better
code.  But not all the time.  Sometimes, to get our jobs done, we need
to look inside the modules we are using; modules which weren't
designed to be extended in the way we have in mind.  Yes, it makes it
so your code could break when the module is updated by the authors,
however it beats the pants off of implementing the module yourself,
especially if you don't know anything about that domain.  It is an
easy trade to exchange a little maintenance effort when the author
updates the module for the reuse of 10,000 lines of code.

Broken encapsulation is not the root of all evil.  However, it's
possible that premature broken encapsulation is; that is, when you
trade breaking encapsulation for a little extra work to create a
better design, you're digging yourself into a hole.  But sometimes a
better design isn't "a little extra work" away; sometimes it's a heck
of a lot.

Reply via email to