[Pharo-project] Beginner question about "self" in block

Ben Coman btc at openInWorld.com
Fri Jan 27 00:11:53 EST 2012


Stéphane Ducasse wrote:
> Welcome
>
>
>   
>> Hi, I have one begginer question. It is may be simple, but it very baffles me.
>>
>> I am reading Pharo by Example (great book btw, thanks!). I'm in chapter two where I'm creating Lights Out game. There is this simple code http://pastebin.com/eQregZ35. What baffles me is line 10. I assign "Block of code" to mouseAction variable of LOCell. In this Block, there is "self", that obviously refers to LOGame object in that time. But when is this Block actualy EVALUATED (when I click on Cell), "self" should be reffering to LOCell object, isn't it? If I inspect one LOCell, inspector shows that it has instance variable
>>     
>
> Here is a draft of a next chapter on block :)
> But I should finish it :)
> ------------------------------------------------------------------------
>
>
> But I want to add how block are implemented at the bye code level so it take times because not that many people are helping, so I have to learn first.
>
> Stef
>   
Thanks Stef.  A very enlightening read.  Its has helped in an example 
I'll relate for other neophytes, and in case there are any traps or 
patterns I am missing.

I have been struggling with how to implement a bidirectional 
relationship between two classes such that consistency is enforced.   
Take for instance the following classes...
  Object subclass: #Book   instanceVariableNames: 'bookTitle library'
  Object subclass: #Library instanceVariableNames: 'libraryName books'

I want both the 'books' and 'library' instvars to remain private - 
meaning that I don't want the default accessors providing direct access 
to either.  Then a method like 'Library>>addBook: aBook' which can 
update its internal state modifying the 'books' collection cannot update 
the internal 'library' state of 'aBook' - without Book having a setter 
method to directly change the 'library' instvar - which I want to avoid 
having.  Trying to resolve this led me into recursion hell with too much 
cross checking and guarding code.

What I was wanting was a way to expose the private state of one object 
to another object in a controlled manner.  So now I think this might be 
achieved like this...

Library>>addBook: aBook
    aBook addToLibrary: self.

Book>>addToLibrary: aLibrary
    aLibrary addBook: self withBackLink: [ :backlinkValue | library := 
backlinkValue ].

Library>>addBook: aBook withBackLink: setBacklinkBlock
    books ifNil: [ books := OrderedCollection new ].
    books add: aBook.
    setBacklinkBlock value: self.

Now having done that, I think I missed an alternative implementation...

Library >> addBook: aBook
    aBook addToLibrary: self withInternalCollection: books

Book>>addToLibrary: aLibrary withInternalCollection: 
libraryInternalBooksCollection
    libraryInternalBooksCollection add: self.
    library := aLibrary.


Book>>addToLibrary: aLibrary
    aLibrary addBook: self.

and I'm not really sure of the pros & cons of each approach.  Thoughts 
anyone?




More information about the Pharo-dev mailing list