Famix-extensions methods which are not real properties

[NicolasAnquetil]

In FamixJava and FamixSmalltalk, some accessing methods are implemented manually. exemple:

FamixJavaMethod >> invokedMethods
    <FMProperty: #invokedMethods type: #FamixJavaMethod> <derived> <multivalued>
    <FMComment: 'The methods invoked by the receiver'>

    ^ self invokedBehaviours select: [ :each | each isMethod ]

- FamixStMethod >> invokedMethods
    <FMProperty: #invokedMethods type: #FamixStMethod> <derived> <multivalued>
    <FMComment: 'The methods invoked by the receiver'>

    ^ self invokedBehaviours select: [ :each | each isMethod ]

They can be found in the Famix-Extensions category

They are met-described, so they appear in mooseDescription allProperties But the setter method is not implemented, so they are actually "half Famix properties"

So either they should not be meta-described, or the corresponding setters should be created

[badetitou]

These properties have the derived pragma. So it is expected that they do not have specific setter? Do you feel they created bugs? Is there any reason you want to have setter? Or maybe it's only because you want to separate derived and not derived properties?

[NicolasAnquetil]

Yes it gives me a bug when I tried to create a copy of an entity (for Orion).

It is not exactly the same as #derived, because TClass >> #methods is also derived and there is a setter (actually two: methods: and addMethod:).

but maybe we should change the meaning of derived? Note that we had several issues related to #derived in the past : #338 #214 #182 #181 #162 #161 #16

This shows that the semantic is not clear

[badetitou]

Ahh indeed! Derived is also used by model exporter. To not export each side of the relation I agree to find another way to express this relations. Maybe <computer property>

However. I think it is important to keep them describe in the metamodel

[NicolasAnquetil]

So there we go:

• create a new pragma
• set it on all relevant properties (the one that are not created by the generator

I am not a big of the name you are proposing (<computer property>) because I don't see how it relates to the characteristics of these properties.

Whoever resolve this issue gets a chance to define its (proper) name. Innitial suggestions:

• <manual> or <humanMade> (manually created, not generated by the generator)
• <queryProperty>, <convenianceProperty (not "full" property with a getter and a setter)
• <extension>

[badetitou]

I was thinking about computed properties but my phone miss fixed it. Query property souds nice to me too

[NicolasAnquetil]

Actually there is a <generated> pragma that the generator puts in the "normal" properties. I am now thinking that we can just filter out those that are not generated...

In this case there would be nothing to do !