Re: Strange behaviour??

[Urs Hoelzle <urs@otis.stanford.edu>]

In <9103122037.AA02416@Sandelman.OCUnix.On.Ca>, Michael Richardson
writes: 

>   I've been thinking about how to implement 'copy-on-write' slots --
> attempts by objects other than the one that actually contains the slot
> to write to it will result in that object getting its own copy of the
> slot. 
>   I was going to try and make the assignment slot private, and catch
> the noPublicSelector:... and make the decision there  (this won't work
> I think)
> 
> [stuff deleted]
>
>   I came across the following behaviour which I don't understand:
> 
> [stuff deleted]
>
> 
>   Now, comment out the line with the " * " (removing the parent):
>
> [stuff deleted]
>
>   WHY the difference? Somehow the local noPublicSelector:... isn't
> getting called. The only other noPublicSelector: I can find from

You're absolutely right: in the first case, noPublicSelector:.. isn't
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."

In your example, we have

    sending method holder = lobby (it's typed in at the prompt)
    private slot holder   = copyWrite first
    receiver              = copyWrite first

We don't have to worry about the private slot holder since it's
identical to the receiver (and thus trivially an ancestor).  The lobby
is an ancestor of the receiver (because of the line marked " * "), and
therefore private access is allowed.

In the second case, the sending method holder (the lobby) is no longer
an ancestor of the receiver.  Consequently, the lookup ignores the
private slot and generates the noPublicSelector:... message because
there is no other matching slot.

Because the lobby is an ancestor of almost every object, you can
access the private slots of all these objects in expressions typed in
at the prompt.  If you put your testing code into some object
unrelated to <copyWrite first>, the behavior would be identical in
both cases.

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").

-Urs