I want relationships for certain modeling purposes What I like is that we should arrive to get a collection of useful slots with optimal implementation instead all of us reinventing the wheel. Stef Le 6/2/15 18:15, Marcus Denker a écrit :
On 06 Feb 2015, at 11:50, Marcus Denker <marcus.denker@inria.fr> wrote:
Next: When building classes with Slots, the class builder need to call back on the slot and hand the class to each. Then the slot can reflectively change the class, e.g. the PropertySlot will check if there is already a hidden property base slot and if not, add it reflectively). This is now done:
https://pharo.fogbugz.com/f/cases/14876/Add-call-back-in-ClassBuilder-to-cal...
For playing with this, in 479:
InstanceVariableSlot subclass: #AccessorSlot slots: { } classVariables: { } category: âPackage'
two methods, #installingIn and #removingFrom:, which are called by the class builder:
installingIn: aClass | reader writer |
reader := String streamContents: [ :str | str nextPutAll: self name; cr;tab; nextPutAll: ' ^'; nextPutAll: self name. ]. writer := String streamContents: [ :str | str nextPutAll: self name; nextPutAll: ': anObject'; cr;tab; nextPutAll: self name; nextPutAll: ':= anObject.'. ]. aClass compile: reader classified: 'accessing'. aClass compile: writer classified: 'accessingâ.
removingFrom: aClass
aClass removeSelector: self name. aClass removeSelector: self name asMutator.
Now we can make a class and see how the accessors are automatically added (and removed when the slot is removed):
Object subclass: #TT slots: { #tttt => AccessorSlot } classVariables: { } category: âPackage'
NOTE: this is an example of what can be done with Slots. It is *not* an example of what *should* be done with Slots. (this we only will know after using them for a while).
Marcus