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.den...@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-call-slots-when-building-a-class
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