Example implementation of associations with Slots in Pharo 4.0
Today I experimented a little with the new Slots feature of Pharo 4.0. As an example I implemented support for associations/relationships. With it you can link two slots together so an update on one side will also update the other side of the association/relationship. I used these Movie and Person classes for testing: Object subclass: #SlotExampleMovie slots: { #name. #year. ToOneAssociationSlot named: #director target: #SlotExamplePerson inverse: #directedMovies. ToManyAssociationSlot named: #actors target: #SlotExamplePerson inverse: #actedInMovies } classVariables: { } category: 'SlotAssociations-Tests-Example' Object subclass: #SlotExamplePerson slots: { #name. ToManyAssociationSlot named: #directedMovies target: #SlotExampleMovie inverse: #director. ToManyAssociationSlot named: #actedInMovies target: #SlotExampleMovie inverse: #actors } classVariables: { } category: 'SlotAssociations-Tests-Example' With this definition the director of a Movie must be a Persion instance. When you set the director of a movie this movie is automatically added to the directedMovies collection of that person. Off course it also works the other way around. It took very little code to add these association slots. I think Slots are a really nice addition to Pharo! If anyone wants to have a look at the code: MCHttpRepository location: 'http://smalltalkhub.com/mc/JanVanDeSandt/Stuff/main' user: '' password: '' Jan.
Hi Jan Excellent! We know exactly whay we want slots and this is exactly for such kind of extensions. you may want to read the paper of Kasper Osterbye http://itu.dk/people/kasper/cv.htm R.11 Kasper Ãsterbye. Associations as a Language Construct. In Proceedings of TOOLS 29, Ed. Richard Michel et.al., Nancy, June 7-10 1999. Page 224-235. (pdf) I would love to have a nice package with such relationships because we used them all the time. I will blog about your nice experience. We should probably find a nicer way to declare them. Stef Le 21/2/15 21:11, Jan van de Sandt a écrit :
Today I experimented a little with the new Slots feature of Pharo 4.0. As an example I implemented support for associations/relationships.
With it you can link two slots together so an update on one side will also update the other side of the association/relationship.
I used these Movie and Person classes for testing:
Object subclass: #SlotExampleMovie slots: { #name. #year. ToOneAssociationSlot named: #director target: #SlotExamplePerson inverse: #directedMovies. ToManyAssociationSlot named: #actors target: #SlotExamplePerson inverse: #actedInMovies } classVariables: { } category: 'SlotAssociations-Tests-Example' Object subclass: #SlotExamplePerson slots: { #name. ToManyAssociationSlot named: #directedMovies target: #SlotExampleMovie inverse: #director. ToManyAssociationSlot named: #actedInMovies target: #SlotExampleMovie inverse: #actors } classVariables: { } category: 'SlotAssociations-Tests-Example'
With this definition the director of a Movie must be a Persion instance. When you set the director of a movie this movie is automatically added to the directedMovies collection of that person. Off course it also works the other way around.
It took very little code to add these association slots. I think Slots are a really nice addition to Pharo! If anyone wants to have a look at the code:
MCHttpRepository location: 'http://smalltalkhub.com/mc/JanVanDeSandt/Stuff/main' user: '' password: ''
Jan.
On 21 Feb 2015, at 21:11, Jan van de Sandt <jvdsandt@gmail.com> wrote:
Today I experimented a little with the new Slots feature of Pharo 4.0. As an example I implemented support for associations/relationships.
Very nice! Can I add this to Pharo4 as an example? My idea is that at first we add these things as examples, and then later take the examples and distill a library of generally useful slots. Marcus
On Mon, Feb 23, 2015 at 9:59 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 21 Feb 2015, at 21:11, Jan van de Sandt <jvdsandt@gmail.com> wrote:
Today I experimented a little with the new Slots feature of Pharo 4.0. As an example I implemented support for associations/relationships.
Very nice! Can I add this to Pharo4 as an example?
Sure, cool!
My idea is that at first we add these things as examples, and then later take the examples and distill a library of generally useful slots.
That sounds like a good approach to get familiar with these kind of new features. Some things I can do to improve the Example - Add an option to make one side of the association readonly. In most situations I think it's a good idea to update an association only from one side to keep things simple. - Whats a better name AssociationSlot or RelationSlot? I'm not sure - As Stéphane said, isn't there a nicer way to declare the associations? - Better error handling Jan.
I haven't played with the relation example yet, but will real soon. Just some initial thoughts... I like RelationSlot. To me association seems one-way while a relation is two-way. btw, Is there some reason to not match the syntax of the often cited paper "Flexible Object Layout" ? I see one advantage is that its easier to read all the slot names vertically aligned. Object subclass: #SlotExampleMovie slots: { #name. #year. #director => ToOneRelationSlot opposite: #directedMovies class: #SlotExamplePerson. #actors => ToManyRelationSlot opposite: #actedInMovies class: #SlotExamplePerson. } classVariables: { } category: 'SlotAssociations-Tests-Example' Also maybe an alternative slot class name so that it reads more like a sentence... "#director related to one #directedMovies in class #SlotExamplePerson" Object subclass: #SlotExampleMovie slots: { #name. #year. #director => RelatedToOne inverse: #directedMovies inClass: #SlotExamplePerson. #actors => RelatedToMany inverse: #actedInMovies inClass: #SlotExamplePerson. } classVariables: { } category: 'SlotAssociations-Tests-Example' Or even... Object subclass: #SlotExampleMovie slots: { #name. #year. #director => OneRelatedTo many: #directedMovies inClass: #SlotExamplePerson. #actors => ManyRelatedTo many: #actedInMovies inClass: #SlotExamplePerson. } classVariables: { } category: 'SlotAssociations-Tests-Example' cheers -ben On Tue, Feb 24, 2015 at 2:33 AM, Jan van de Sandt <jvdsandt@gmail.com> wrote:
On Mon, Feb 23, 2015 at 9:59 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 21 Feb 2015, at 21:11, Jan van de Sandt <jvdsandt@gmail.com> wrote:
Today I experimented a little with the new Slots feature of Pharo 4.0. As an example I implemented support for associations/relationships.
Very nice! Can I add this to Pharo4 as an example?
Sure, cool!
My idea is that at first we add these things as examples, and then later take the examples and distill a library of generally useful slots.
That sounds like a good approach to get familiar with these kind of new features.
Some things I can do to improve the Example - Add an option to make one side of the association readonly. In most situations I think it's a good idea to update an association only from one side to keep things simple. - Whats a better name AssociationSlot or RelationSlot? I'm not sure - As Stéphane said, isn't there a nicer way to declare the associations? - Better error handling
Jan.
Exactly :). In Fame, there is a FMMultivalueLink hierarchy that implement many to one and many to many relations. This implementation exists since before slots and now we should reimplement them with slots. It will make the code so much nicer :). Anyone interested in picking this up? Cheers, Doru On Mon, Feb 23, 2015 at 10:34 PM, Ben Coman <btc@openinworld.com> wrote:
I haven't played with the relation example yet, but will real soon. Just some initial thoughts...
I like RelationSlot. To me association seems one-way while a relation is two-way.
btw, Is there some reason to not match the syntax of the often cited paper "Flexible Object Layout" ? I see one advantage is that its easier to read all the slot names vertically aligned.
Object subclass: #SlotExampleMovie slots: { #name. #year. #director => ToOneRelationSlot opposite: #directedMovies class: #SlotExamplePerson. #actors => ToManyRelationSlot opposite: #actedInMovies class: #SlotExamplePerson. } classVariables: { } category: 'SlotAssociations-Tests-Example'
Also maybe an alternative slot class name so that it reads more like a sentence... "#director related to one #directedMovies in class #SlotExamplePerson"
Object subclass: #SlotExampleMovie slots: { #name. #year. #director => RelatedToOne inverse: #directedMovies inClass: #SlotExamplePerson. #actors => RelatedToMany inverse: #actedInMovies inClass: #SlotExamplePerson. } classVariables: { } category: 'SlotAssociations-Tests-Example'
Or even...
Object subclass: #SlotExampleMovie slots: { #name. #year. #director => OneRelatedTo many: #directedMovies inClass: #SlotExamplePerson. #actors => ManyRelatedTo many: #actedInMovies inClass: #SlotExamplePerson. } classVariables: { } category: 'SlotAssociations-Tests-Example'
cheers -ben
On Tue, Feb 24, 2015 at 2:33 AM, Jan van de Sandt <jvdsandt@gmail.com> wrote:
On Mon, Feb 23, 2015 at 9:59 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 21 Feb 2015, at 21:11, Jan van de Sandt <jvdsandt@gmail.com> wrote:
Today I experimented a little with the new Slots feature of Pharo 4.0. As an example I implemented support for associations/relationships.
Very nice! Can I add this to Pharo4 as an example?
Sure, cool!
My idea is that at first we add these things as examples, and then later take the examples and distill a library of generally useful slots.
That sounds like a good approach to get familiar with these kind of new features.
Some things I can do to improve the Example - Add an option to make one side of the association readonly. In most situations I think it's a good idea to update an association only from one side to keep things simple. - Whats a better name AssociationSlot or RelationSlot? I'm not sure - As Stéphane said, isn't there a nicer way to declare the associations? - Better error handling
Jan.
-- www.tudorgirba.com "Every thing has its own flow"
On 23 Feb 2015, at 22:34, Ben Coman <btc@openInWorld.com> wrote:
I haven't played with the relation example yet, but will real soon. Just some initial thoughts...
I like RelationSlot. To me association seems one-way while a relation is two-way.
btw, Is there some reason to not match the syntax of the often cited paper "Flexible Object Layout" ? I see one advantage is that its easier to read all the slot names vertically aligned.
Object subclass: #SlotExampleMovie slots: { #name. #year. #director => ToOneRelationSlot opposite: #directedMovies class: #SlotExamplePerson. #actors => ToManyRelationSlot opposite: #actedInMovies class: #SlotExamplePerson. } classVariables: { } category: 'SlotAssociations-Tests-Example'
Also maybe an alternative slot class name so that it reads more like a sentence... "#director related to one #directedMovies in class #SlotExamplePerson"
Object subclass: #SlotExampleMovie slots: { #name. #year. #director => RelatedToOne inverse: #directedMovies inClass: #SlotExamplePerson. #actors => RelatedToMany inverse: #actedInMovies inClass: #SlotExamplePerson. } classVariables: { } category: 'SlotAssociations-Tests-Example'
Something like those would be good⦠yes, I think having the slot name in front is important. Marcus
Hello, Thanks for your suggestions. I have improved the naming and definition to this: Object subclass: #SlotExampleMovie slots: { #name. #year. #director => ToOneRelationSlot inverse: #directedMovies inClass: #SlotExamplePerson. #actors => ToManyRelationSlot inverse: #actedInMovies inClass: #SlotExamplePerson } classVariables: { } category: 'SlotAssociations-Tests-Example' Because it is for now just an example I haven't renamed the Slot classes yet. Jan. On Tue, Feb 24, 2015 at 8:03 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 23 Feb 2015, at 22:34, Ben Coman <btc@openInWorld.com> wrote:
I haven't played with the relation example yet, but will real soon. Just some initial thoughts...
I like RelationSlot. To me association seems one-way while a relation is two-way.
btw, Is there some reason to not match the syntax of the often cited paper "Flexible Object Layout" ? I see one advantage is that its easier to read all the slot names vertically aligned.
Object subclass: #SlotExampleMovie slots: { #name. #year. #director => ToOneRelationSlot opposite: #directedMovies class: #SlotExamplePerson. #actors => ToManyRelationSlot opposite: #actedInMovies class: #SlotExamplePerson. } classVariables: { } category: 'SlotAssociations-Tests-Example'
Also maybe an alternative slot class name so that it reads more like a sentence... "#director related to one #directedMovies in class #SlotExamplePerson"
Object subclass: #SlotExampleMovie slots: { #name. #year. #director => RelatedToOne inverse: #directedMovies inClass: #SlotExamplePerson. #actors => RelatedToMany inverse: #actedInMovies inClass: #SlotExamplePerson. } classVariables: { } category: 'SlotAssociations-Tests-Example'
Something like those would be good⦠yes, I think having the slot name in front is important.
Marcus
On 27 Feb 2015, at 11:46, Jan van de Sandt <jvdsandt@gmail.com> wrote:
Hello,
Thanks for your suggestions. I have improved the naming and definition to this:
Object subclass: #SlotExampleMovie slots: { #name. #year. #director => ToOneRelationSlot inverse: #directedMovies inClass: #SlotExamplePerson. #actors => ToManyRelationSlot inverse: #actedInMovies inClass: #SlotExamplePerson } classVariables: { } category: 'SlotAssociations-Tests-Example'
Because it is for now just an example I haven't renamed the Slot classes yet.
Thanks! I will add the associations as examples to Pharo4 (today I think) Marcus
Could someone explain why the "ToOne" and "ToMany" are the preferred semantics for the class names versus OneRelatedTo or RelatedToOne ? To me, "ToOne" feels like its describing the #directedMovies part. I guess it makes sense if you are looking in towards #director. cheers -ben On Fri, Feb 27, 2015 at 7:51 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 27 Feb 2015, at 11:46, Jan van de Sandt <jvdsandt@gmail.com> wrote:
Hello,
Thanks for your suggestions. I have improved the naming and definition to this:
Object subclass: #SlotExampleMovie slots: { #name. #year. #director => ToOneRelationSlot inverse: #directedMovies inClass: #SlotExamplePerson. #actors => ToManyRelationSlot inverse: #actedInMovies inClass: #SlotExamplePerson } classVariables: { } category: 'SlotAssociations-Tests-Example'
Because it is for now just an example I haven't renamed the Slot classes yet.
Thanks! I will add the associations as examples to Pharo4 (today I think)
Marcus
On 04 Mar 2015, at 06:20, Ben Coman <btc@openInWorld.com> wrote:
Could someone explain why the "ToOne" and "ToMany" are the preferred semantics for the class names versus OneRelatedTo or RelatedToOne ? To me, "ToOne" feels like its describing the #directedMovies part. I guess it makes sense if you are looking in towards #director. cheers -ben
Right now I care more about fixing all bugs to make the examples actually loadable⦠there are so many details⦠e.g. integrating the examples broke the build as the code that generates the #initialize method asked for initialsâ¦
On Fri, Feb 27, 2015 at 7:51 PM, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
On 27 Feb 2015, at 11:46, Jan van de Sandt <jvdsandt@gmail.com <mailto:jvdsandt@gmail.com>> wrote:
Hello,
Thanks for your suggestions. I have improved the naming and definition to this:
Object subclass: #SlotExampleMovie slots: { #name. #year. #director => ToOneRelationSlot inverse: #directedMovies inClass: #SlotExamplePerson. #actors => ToManyRelationSlot inverse: #actedInMovies inClass: #SlotExamplePerson } classVariables: { } category: 'SlotAssociations-Tests-Example'
Because it is for now just an example I haven't renamed the Slot classes yet.
Thanks! I will add the associations as examples to Pharo4 (today I think)
Marcus
we should ask a modeling expert. We have one in the team. Le 4/3/15 06:20, Ben Coman a écrit :
Could someone explain why the "ToOne" and "ToMany" are the preferred semantics for the class names versus OneRelatedTo or RelatedToOne ? To me, "ToOne" feels like its describing the #directedMovies part. I guess it makes sense if you are looking in towards #director. cheers -ben
On Fri, Feb 27, 2015 at 7:51 PM, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
> On 27 Feb 2015, at 11:46, Jan van de Sandt <jvdsandt@gmail.com <mailto:jvdsandt@gmail.com>> wrote: > > Hello, > > Thanks for your suggestions. I have improved the naming and definition to this: > > Object subclass: #SlotExampleMovie > slots: { > #name. > #year. > #director => ToOneRelationSlot inverse: #directedMovies inClass: #SlotExamplePerson. > #actors => ToManyRelationSlot inverse: #actedInMovies inClass: #SlotExamplePerson } > classVariables: { } > category: 'SlotAssociations-Tests-Example' > > Because it is for now just an example I haven't renamed the Slot classes yet. >
Thanks! I will add the associations as examples to Pharo4 (today I think)
Marcus
On 27 Feb 2015, at 12:51, Marcus Denker <marcus.denker@inria.fr> wrote:
On 27 Feb 2015, at 11:46, Jan van de Sandt <jvdsandt@gmail.com> wrote:
Hello,
Thanks for your suggestions. I have improved the naming and definition to this:
Object subclass: #SlotExampleMovie slots: { #name. #year. #director => ToOneRelationSlot inverse: #directedMovies inClass: #SlotExamplePerson. #actors => ToManyRelationSlot inverse: #actedInMovies inClass: #SlotExamplePerson } classVariables: { } category: 'SlotAssociations-Tests-Example'
Because it is for now just an example I haven't renamed the Slot classes yet.
Thanks! I will add the associations as examples to Pharo4 (today I think)
It took a bit longer as loading the examples revealed a bug, but now they are in Pharo4 update #534. Marcus
On 23 Feb 2015, at 19:33, Jan van de Sandt <jvdsandt@gmail.com> wrote:
On Mon, Feb 23, 2015 at 9:59 AM, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
On 21 Feb 2015, at 21:11, Jan van de Sandt <jvdsandt@gmail.com <mailto:jvdsandt@gmail.com>> wrote:
Today I experimented a little with the new Slots feature of Pharo 4.0. As an example I implemented support for associations/relationships.
Very nice! Can I add this to Pharo4 as an example?
Sure, cool!
Ok, I will do that. Marcus
participants (5)
-
Ben Coman -
Jan van de Sandt -
Marcus Denker -
stepharo -
Tudor Girba