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

Re: Stupid Newbie Question

Thread Previous | Thread Next
From:
Michael G Schwern
Date:
November 15, 2001 20:35
Subject:
Re: Stupid Newbie Question
Message ID:
20011115233238.U31399@blackrider
On Thu, Nov 15, 2001 at 05:49:34PM -0800, John Rudd wrote:
> So, for example, lets say I have an object $foo, which is an instance of
> Class A.  In one method, foo tries to access an instance variable of
> $bar, an instance of Class B (not inherited from Class A).

This is a naughty thing to do.  $bar should have a set of accessor
methods if you're really worried.  Read on.


> If $bar's instance variables are somehow hidden

Looks like the whole "an object is just a hash reference" paradigm
might be mutating some to allow better data hiding.  There was a big
thread on perl6-language about this just recently.


> I could then have the Class B auto(vivify|glob) routine perform
> checks on the identity and heritage of $foo, and then decide what to
> do about the request.

There's a whole host of modules that make writing accessors cheap,
Class::Accessor and Class::Struct for example.  Once you're inside an
accessor method you can do whatever access checking you like.

If I'm reading the tea leaves correctly, Perl 6 will address this sort
of thing with some variation on slots.  So you can declare "for *this*
list of instance variables, make me some simple accessors".  So
C<$foo->bar = 'this'> == C<$foo->{bar} = 'this'>.  So rather than
using AUTOVIVIFIY you'd use slots and accessor methods.

In theory, these slots should be closer to the speed of a regular
hash than accessor methods currently are in perl5.


> 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?


> The question in my brain, since I don't know perl's internals in very
> much detail, is how hard is it to figure out who the caller was?

caller().  Or is something more involved?


> It's not just a matter of knowing what package the invoking
> subroutine belonged to, because instances of the same class might
> have have access to eachother's instance variables (ala Smalltalk).
> It further complicates things if you want to extend it to include
> C++ style "friend" functions (I don't, but others might).

    die "Sorry, private method"       unless caller eq ref $self;

    die "Sorry, protected method"     unless caller->isa(ref $self);

    die "Sorry, you're not my friend" 
        unless exists $self->{_my_friends}{caller()};

That about covers basic method privacy.


> (yes, I know you can emulate class variables via package globals like
> $Class::blah, but I'm trying to look at it in a more uniform point of
> view so that you can fully treat Classes themselves as being objects)

Class::Data::Inheritable anyone? :)


-- 

Michael G. Schwern   <schwern@pobox.com>    http://www.pobox.com/~schwern/
Perl Quality Assurance	    <perl-qa@perl.org>	       Kwalitee Is Job One
"You killed my fish?"
"Why does that pickle you?"
	http://sluggy.com/d/010204.html

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