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

Ben Coman btc at openInWorld.com
Fri Jan 27 19:26:03 CET 2012


Stéphane Ducasse wrote:
> I guess that in naked objects book they discussed some patterns for relationships.
> What I would love to have is first class slots so that we can easily express relationships like the ones you describe.
> But I have too busy.
> I'm rereading the paper of toon, camillo et all to see what we could reasonably do.
>   
I found the description of Bidrectional Associations interesting [1], as 
well as the naming convention for Derived Fields and Actions.

[1] http://www.nakedobjects.org/book/section19.html
> Stef
>
> On Jan 27, 2012, at 6:11 AM, Ben Coman wrote:
>
>   
>> 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-project mailing list