develooper Front page | perl.perl5.porters | Postings from March 2011

RE: Revising Perl's OO docs - a new OO tutorial

Thread Previous | Thread Next
From:
Jan Dubois
Date:
March 8, 2011 11:29
Subject:
RE: Revising Perl's OO docs - a new OO tutorial
Message ID:
007101cbddc7$1e82a560$5b87f020$@activestate.com
On Tue, 08 Mar 2011, Steffen Mueller wrote:
> On 03/07/2011 10:45 PM, Jan Dubois wrote:
> > You actually need 2 hashes per object for this though, one for the
> > externally visible tied interface, and one to store the internal
> > object data.
> 
> I just encountered such an interface at work in conjunction with
> inside-out objects to expose the IOOs as hashref-alikes.
> 
> This must be the single most horrible API in Perl ever. It abuses tie.
> It pretends to be a hash when it is not for no good reason. It can
> return lists from $obj->{foo}. But worst of all: It requires programmers
> to think hard about whether they're violating encapsulation or not!
> Please. Make it stop.

I assume you are talking about the particular implementation you have
encountered at work.

In general you are of course dead wrong: the tie mechanism *protects*
your internal object state. The part that is soo wrong is that by
default the internal implementation on an object (e.g. hash ref) leaks
out, and users can access it by mistake. $obj->{foo} should *not* give
you access to the object internals, and the tie mechanism gives you
active control over it.

There are performance arguments against it, but from an encapsulation
point of view it is far superior to the "here is a blessed hashref, please
pretend you don't know this" practice.

Cheers,
-Jan



Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About