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.
On 04 Mar 2015, at 06:20, Ben Coman b...@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
On 27 Feb 2015, at 12:51, Marcus Denker marcus.den...@inria.fr wrote:
On 27 Feb 2015, at 11:46, Jan van de Sandt jvdsa...@gmail.com wrote:
Hello,
Thanks for your suggestions. I have improved the naming and definition to
this:
Object subclass: #SlotExampleMovie
slots: {
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
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:
On 27 Feb 2015, at 11:46, Jan van de Sandt jvdsa...@gmail.com wrote:
Hello,
Thanks for your suggestions. I have improved the naming and definition to
this:
Object subclass: #SlotExampleMovie
slots: {
#name.
#year.
#director =
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
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,
On 21 Feb 2015, at 21:11, Jan van de Sandt jvdsa...@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
On 23 Feb 2015, at 22:34, Ben Coman b...@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
On 23 Feb 2015, at 19:33, Jan van de Sandt jvdsa...@gmail.com wrote:
On Mon, Feb 23, 2015 at 9:59 AM, Marcus Denker marcus.den...@inria.fr
mailto:marcus.den...@inria.fr wrote:
On 21 Feb 2015, at 21:11, Jan van de Sandt jvdsa...@gmail.com
mailto:jvdsa...@gmail.com wrote:
Today I
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
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
13 matches
Mail list logo
