Re: parentSelectors and childrenAccessors refactoring

Hi,

 

I changed the implementation of parentSelectors and childrenAccessors.

It is not based on <MSEParentProperty> like suggested in previous discussion but on <container> which is a pragma that is recognized by the meta meta model (Fame).

The implementation of the parentSelector method is consequently simpler and based on Fame:

parentSelector

       ^ self mooseDescription allAttributes select: #isContainer thenCollect: #implementingSelector

 

The same for childrenAccessors which is now based on Fame too:

childrenAccessors

       childrenAccessors

              ifNil: [ childrenAccessors := (self allDeclaredProperties

                           select: [ :fm3Prop |

                                  fm3Prop hasOpposite

                                         ifTrue: [ fm3Prop opposite isContainer ]

                                         ifFalse: [ false ] ]) collectAsSet: [ :prop | prop name ] ].

       ^ childrenAccessors

 

Instead of:

childrenAccessors

       childrenAccessors

              ifNil: [ childrenAccessors := (self allDeclaredProperties

                           select: [ :fm3Prop |

                                  | tmpClass |

                                  tmpClass := fm3Prop type implementingClass.

                                  tmpClass

                                         ifNotNil: [ ((tmpClass inheritsFrom: FAMIXNamedEntity) or: [ tmpClass = FAMIXNamedEntity ])

                                                       and: [ tmpClass parentSelector

                                                                     anySatisfy:

                                                                           [ :sel | ((tmpClass lookupSelector: sel) pragmas detect: [ :p | p keyword = 'MSEProperty:type:opposite:' ]) arguments third = fm3Prop name ] ] ]

                                         ifNil: [ false ] ]

                           thenCollect: [ :prop | prop name ]) flattened asSet ].

       ^ childrenAccessors

Consequently, for other models, the pragma <container> should be implemented on all the selectors referencing the containers of the entity itself.

 

Cheers,

Vincent

 

> -----Message d'origine-----

> De : Moose-dev [[hidden email]] De la part de

> Tudor Girba

> Envoyé : dimanche 18 septembre 2016 15:33

> À : Moose-related development

> Objet : [Moose-dev] Re: parentSelectors

>

> Hi,

>

> > On Sep 18, 2016, at 3:29 PM, Blondeau Vincent

> <[hidden email]> wrote:

> >

> >

> > ________________________________________

> > De : Moose-dev [[hidden email]] de la part de

> > Tudor Girba [[hidden email]] Date d'envoi : dimanche 18

> > septembre 2016 15:17 À : Moose-related development Objet : [Moose-

> dev]

> > Re: parentSelectors

> >

> > Hi,

> >

> >> On Sep 18, 2016, at 2:57 PM, Vincent BLONDEAU

> <[hidden email]> wrote:

> >>

> >>

> >>

> >> From: Moose-dev [[hidden email]] On

> >> Behalf Of Tudor Girba

> >> Sent: dimanche 18 septembre 2016 11:09

> >> To: Moose-related development

> >> Subject: [Moose-dev] parentSelectors

> >>

> >> Hi,

> >>

> >> Hi,

> >>

> >>

> >> I just saw that the way the parent selectors are being defined was

> changed. In general, please announce deep changes like these on the mailing

> list.

> >>

> >> Indeed, I done it last week and didn’t announced it yet on the mailing list.

> >>

> >> If I understand correctly, the goal was to make it easier for extensions to

> specify the parentSelectors. This is a good goal, but there are two problems

> with the current solution:

> >>

> >> Yes, there was some problems if you extend the FAMIX metamodel with

> some classes, as it is done with Orion. The parentSelectors are in fact not

> described in the fame metamodel and cannot be used easily in the

> subclasses.

> >>

> >> 1. The parentSelectors should be extensible. Right now, they are defined

> in one method returning a collection of strings. Instead, it would be better to

> have them described directly in the selector method. For example, we could

> have:

> >>

> >> FAMIXType>>container

> >>            <MSEProperty: #container type: #FAMIXContainerEntity opposite:

> #types>

> >>            <MSEComment: 'Container entity to which this type belongs to.

> Container is a namespace, not a package (Smalltalk).'>

> >>            <MSEParentProperty>

> >>            ^container

> >>

> >> This would also allow us to extend existing classes with annotations that

> can be selectors.

> >>

> >> 2. Right now, the parentSelectors are defined on the instance side as an

> MSE property:

> >>

> >> FAMIXType>>parentSelectors

> >>            <MSEProperty: #parentSelectors type: #String>

> >>            <multivalued>

> >>            ^ #(container parentPackage)

> >>

> >> This is incorrect given that they describe the type, not the instance. For

> example, one consequence is that now we serialize this information (check

> MooseModel>>testExport which fails right now). Instead, let’s go for

> solution from point 1.

> >>

> >> What do you think?

> >>

> >> I agree that this property is a type property. But, in fame we cannot

> define such kind of property. To do it, we can:

> >> -          Don’t use the Fame meta model (previous solution)

> >> -          Use the instance meta descriptions that are already defined meta

> model (current solution bu not the best)

> >> -          Define some new properties in the metamodel, as you propose. But

> in the 2 points suggested, we have to change the MSE importer and the

> metamodel to take into account the new pragmas (in “annotation” or in the

> selectors by MSEParentProperty).

> >> Do you think that is a good idea ?

> >>        If, we do that, I think the solution in point 1 is better.

> >>

> >> For the current failing test, we can add <derived>. This way the

> >> information will not be serialized

> >

> > The MSE property is about an instance. So, marking it with <derived> does

> not work because we are mixing levels of abstractions.

> >

> > <I know it is just temporary.

> >

> > What we want is to make the selector discoverable through reflection. This

> is at the level of Pharo code. So, by annotating the concrete property we can

> discover them properly and have subclasses know about them.

> >

> >

> > <So you don't think that is should be described in the meta model? and just

> use the Pharo reflexion to retrieve the methods?

>

> I think we only use this in Pharo at runtime, so adding it to the meta-model is

> not particularly useful. That is why, let’s keep it simple.

>

> Cheers,

> Doru

>

>

>

> > Cheers,

> > Vincent

> >

> >

> > Cheers,

> > Doru

> >

> >

> >> Cheers,

> >> Vincent

> >>

> >>

> >> Cheers,

> >> Doru

> >>

> >>

> >>

> >> --

> >> www.tudorgirba.com

> >> www.feenk.com

> >>

> >> "It's not how it is, it is how we see it."

> >>

> >> _______________________________________________

> >> Moose-dev mailing list

> >> [hidden email]

> >> https://www.list.inf.unibe.ch/listinfo/moose-dev

> >

> > --

> > www.tudorgirba.com

> > www.feenk.com

> >

> > "Obvious things are difficult to teach."

> >

> >

> >

> >

> > _______________________________________________

> > Moose-dev mailing list

> > [hidden email]

> > https://www.list.inf.unibe.ch/listinfo/moose-dev

> >

> >

> !!!************************************************************

> *******

> > ****************** "Ce message et les pièces jointes sont

> > confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut

> également être protégé par le secret professionnel. Si vous recevez ce

> message par erreur, merci d'en avertir immédiatement l'expéditeur et de le

> détruire. L'intégrité du message ne pouvant être assurée sur Internet, la

> responsabilité de Worldline ne pourra être recherchée quant au contenu de

> ce message. Bien que les meilleurs efforts soient faits pour maintenir cette

> transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à

> cet égard et sa responsabilité ne saurait être recherchée pour tout dommage

> résultant d'un virus transmis.

> >

> > This e-mail and the documents attached are confidential and intended

> solely for the addressee; it may also be privileged. If you receive this e-mail

> in error, please notify the sender immediately and destroy it. As its integrity

> cannot be secured on the Internet, the Worldline liability cannot be triggered

> for the message content. Although the sender endeavours to maintain a

> computer virus-free network, the sender does not warrant that this

> transmission is virus-free and will not be liable for any damages resulting

> from any virus transmitted.!!!"

> > _______________________________________________

> > Moose-dev mailing list

> > [hidden email]

> > https://www.list.inf.unibe.ch/listinfo/moose-dev

>

> --

> www.tudorgirba.com

> www.feenk.com

>

> "There are no old things, there are only old ways of looking at them."

>

>

>

>

> _______________________________________________

> Moose-dev mailing list

> [hidden email]

> https://www.list.inf.unibe.ch/listinfo/moose-dev