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.
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? >
