The problem is that a relation may be one to one, one to many, many to one or many to many. In each name, the first word refers to upper source multiplicity and the last word to the upper target multiplicity. So according to me RelatedToOne has not the same meaning than OneRelatedTo or ToMany. I am not sure that you want to describe the source multiplicity, so ToOne and ToMany seem more adapted. In Java persistance is specified with the @OneToOne, @OneToMany, @ManyToOne and @ManyToMany annotations. Anne Le 5 mars 2015 à 08:10, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> a écrit :

-------- Message transféré -------- Sujet : Re: [Pharo-dev] Example implementation of associations with Slots in Pharo 4.0 Date : Wed, 4 Mar 2015 13:20:45 +0800 De : Ben Coman <btc@openInWorld.com> Répondre à : Pharo Development List <pharo-dev@lists.pharo.org> Pour : Pharo Development List <pharo-dev@lists.pharo.org>

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