we want that in pharo. Since years... Stef On Jan 27, 2012, at 7:26 PM, Ben Coman wrote:
> 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? >>> >>> >> >> >> >> > >
