develooper Front page | perl.perl6.language.objects | Postings from November 2001

Re: Stupid Newbie Question

Thread Previous | Thread Next
Michael G Schwern
November 16, 2001 10:32
Re: Stupid Newbie Question
Message ID:
On Fri, Nov 16, 2001 at 07:26:37AM -0800, John Rudd wrote:
> Smalltalk doesn't give you any privacy options, but it does dictate a
> certain degree of privacy.  Smalltalk is big on "information hiding" as
> part of the whole "OOP is an extension of Abstract Data Typing" concept.
> 1) Methods are always public
> 2) Variables are always private (and in this case that means that other
> instances may not view the instance variables of an object; I don't
> recall whether the class can see the ivars of its instances but I'm
> pretty sure it can't).

Ahh, ok.

> (this is completely contrary to the mindset expressed in one of the perl
> books about "if you didn't want people to directly access the ivar via
> $obj->{stuff}, then you should have given them an accessor method for
> getting at the data" ... this contradicts anything I've ever come across
> wrt OOP, where "information hiding" is the norm and where if you aren't
> given an accessor method, then you have no business with (and hopefully no
> ability for) direct access to the ivar.

Isn't that what it said?  Don't screw around with $obj->{stuff}, do
your work via $obj's methods.

> In Smalltalk, the rampant creation of accessor methods without
> reguard to whether the information ought to be available to the
> public, or an attempt to violate the abstract data typing of the
> object by an outside programmer, would be considered "bad
> programming style".

I think you're misinterpreted.  It's not saying "create an accessor
method for everything, YAY!"  It's saying, "create an accessor method
for what you want made public."

A concession to Perl's swiss-cheese OO model.  It smells like Perl 6
will have something a little better than the "stick everything in a
hash ref" model.

Remember, you can hide something by just throwing a sheet over it.
"Information hiding" does not necessitate locking it up in a box and
placing a guard in front of it.

PS If you really want to get psycho about guarding against
unauthorized $obj->{foo} access, you can always make $obj a tied
hash. :)  That way, madness lies.

> Re: "caller()"
> As I said in my previous message, knowing the package isn't really enough.

You're right, I was thinking "private" == "called by an instance of
the same class".  It's "called by the same instance".  Can't do what
you want with caller().  Hmmm... the debugger can get at the caller's
arguments somehow.

There's a strange tug-of-war between the people who want more privacy
for OO and people who want less privacy so they can write debuggers
and serialization and marshelling and Acme modules.  I think what
would work is something like what Ruby does.  It has explicit ways to
declare things private, public and protected, but it also has explicit
ways to let anyone shut it off.

At least that way it's hard to ->accidentally<- violate encapsulation.
Violating encapsulation on purpose is fine.


Michael G. Schwern   <>
Perl Quality Assurance	    <>	       Kwalitee Is Job One
Sometimes you eat the path, sometimes the path eats you.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About