Re: Strange behaviour??

[mcr@Sandelman.OCUnix.On.Ca (Michael Richardson)]

On Mar 12,  7:20pm, Urs Hoelzle wrote:
} In <9103122037.AA02416@Sandelman.OCUnix.On.Ca>, Michael Richardson
} writes: 
} 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
assignment. 
  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.