From: Michael G Schwern <[EMAIL PROTECTED]>
>On Thu, Nov 15, 2001 at 05:49:34PM -0800, John Rudd wrote:
>> That way you could choose to impliment Smalltalk or C++ style
>> protections (public, private, protected, etc)
>
>Last I checked Smalltalk had no privacy protection.
>
>> So, for Smalltalk type semantics, if $foo != $bar, the
>> request will throw some sort of exeption indicating that $foo isn't
>> allowed to see $bar's instance variables. But, if $foo == $bar, then
>> the actual value will be found and returned.
>
>... Smalltalk? not allowed? You sure about that? Or is this
>something you hacked together with doesNotExist?
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).
So, the only way for an outside entity see an object's ivar is if you
define an accessor method for it. If you don't define that method,
then outside entities can't see it at all.
(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. 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". Yet, the statement from the perl book in question
seems to embrace this "bad programmign style" so strongly as to blame the
class implimentor for not catering to the violating outside programmer.)
(note: I'm not meaning to say "perl got it wrong" or "the mindset of
that author was wrong", just that it's directly the opposite of any
OO mindset I had seen before I learned perl OO-isms ... and I'm merely
musing about whether or not auto(vivify|glob) will allow me to build
up such a stronger sense of information hiding.)
Re: "caller()"
As I said in my previous message, knowing the package isn't really enough.
In order to support strong information hiding, you need to know not just
the package of the calling object, but the actual identity of the calling
object. Consider:
package A;
sub foo {
my $self = shift;
my $bar = shift;
$bar->blah();
}
package B;
sub blah {
my $self = shift;
my ($z);
$z = caller();
if ($z == $self) { # not technically correct, but semantically what
# I'm talking about
# same object, let it do stuff
}
else {
# not the same object, complain
}
}
sub blarg {
my $self = shift;
my $target = shift;
$target->blah();
}
package main;
$a = A->new();
$b = B->new();
$c = A->new();
# and, we have some $d, and we don't know if it was created via:
# $d = B->new();
# or
# $d = $b;
$a->foo($b); # statement 1
$c->foo($b); # statement 2
$d->blarg($b); # statement 3
Ok, in the 3 statements you've got 3 different things that eventually get
to &B::blah(). $z wont be any different for statement 1 or statement 2
because caller() only tells us the package, not the identity. Even if you
were to depend upon the fact that $z wont be equal to "B", this only helps
you in the first 2 statements. In statement 3, this doesn't help you at
all, because all caller() tells you is that they're of the same package,
not whether they were the same object.
All perl actually allows me to do for the incorrect if-confidtion above is:
if ($self->isa($z)) {
which isn't good enough for what I'm talking about. If $d and $b are
seperate instances, then the corrected if-condition wont differentiate
between them. This wont help you with strong information hiding.
For what I was asking, caller would have to return something equal to $a
for statement 1, $c for statement 2, and $d for statement 3. Then my
original if-condidition works and allows you to build up something for
strong information hiding.
