On Sat, Feb 7, 2015 at 5:13 AM, stepharo <[email protected]> wrote: > 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 >
In the Flexible Object Layouts paper, it was first class relationships that really caught my eye. Thats what I am hoping for to start having a dive into Slots. And since the paper says "no mainstream OOPL provides first-class relationships as a programming construct" it might be a nice feature to advertise with Pharo 4 release. "First-class relationships" is quite a catchy term ? cheers -ben > > Le 6/2/15 18:15, Marcus Denker a écrit : > > On 06 Feb 2015, at 11:50, Marcus Denker <[email protected]> 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 >> >> >> >> >> > >
