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?
