[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Strange behaviour??
On Mar 12, 7:20pm, Urs Hoelzle wrote:
} In <9103122037.AA02416@Sandelman.OCUnix.On.Ca>, Michael Richardson
} called -- because the access is legal, i.e. the send *does* find the
} private slot and is allowed to access it. From the reference manual,
} section 5.4 (page II-17):
} "A private slot is accessible if both the sending method holder
} and the private slot holder are ancestors of the receiver."
I recall reading this.
I didn't quite understand it at the time though. (Also, a couple of
key pages seem to have disappeared from my copy of the manual. I'll
have to borrow Danny's copy and photocopy them.)
In essense, I had understood that private slots meant that the
sending method holder had to BE the receiver.
Essentially, I wanted to have a 'public' read slot, a private
assignment slot, and a public keyword slot that would do some
crunching before calling the private slot to actually do the
I think I'll have to make do with two different named slots.
(Now all I need is programming actions. I would guess the problem was
with invalidating the code cache?)
Thanks for your help.
} The above-cited definition of privacy is somewhat abstract, I agree.
} But after all, that's what definitions are for :-) The motivation for
} all of this can be found in the "Parent are Shared Objects" paper
} (section 3.2, "The Meaning of Privacy").
I'll take another look.