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 [mailto:moose-dev-bounces@list.inf.unibe.ch] 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
> <vincent.blondeau@worldline.com> wrote:
> >
> >
> > ________________________________________
> > De : Moose-dev [moose-dev-bounces@list.inf.unibe.ch] de la part de
> > Tudor Girba [tudor@tudorgirba.com] 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
> <vincent.blondeau@polytech-lille.net> wrote:
> >>
> >>
> >>
> >> From: Moose-dev [mailto:moose-dev-bounces@list.inf.unibe.ch] 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
> >> Moose-dev@list.inf.unibe.ch
> >>
https://www.list.inf.unibe.ch/listinfo/moose-dev
> >
> > --
> > www.feenk.com
> >
> > "Obvious things are difficult to teach."
> >
> >
> >
> >
> > _______________________________________________
> > Moose-dev mailing list
> > Moose-dev@list.inf.unibe.ch
> >
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
> > Moose-dev@list.inf.unibe.ch
> >
https://www.list.inf.unibe.ch/listinfo/moose-dev
>
> --
>
> "There are no old things, there are only old ways of looking at them."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list