On Sat, Feb 7, 2015 at 5:13 AM, stepharo <stepharo@free.fr> 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 <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-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
�� �� �� ��