I'm experimenting with generating metamodels using FamixNG. I generated an MSE from it using 'FamixTypeScriptMetamodel.mse' asFileReference writeStreamDo: [ :writeStream | FamixTSModel metamodel exportOn: writeStream ], and got some results that don't look like they respect the grammar (see the (type: (ref: String))) line below). Because of this, my parser can't read it. Is this a bug? Maybe my metamodel is missing some entities (I can't find anything with (name 'String'))?

(
	(FM3.Package (id: 1)
		(name 'Tagging')
		(classes
			(FM3.Class (id: 2)
				(name 'Category')
				(abstract false)
				(package (ref: 1))
				(superclass (ref: 3))
				(properties
					(FM3.Property (id: 4)
						(name 'name')
						(class (ref: 2))
						(container false)
						(derived false)
						(multivalued false)
						(type (ref: String)))
					(FM3.Property (id: 5)
						(name 'markedTags')
						(class (ref: 2))
						(container false)
						(derived false)
						(multivalued true)
						(opposite (ref: 6))
						(type (ref: 7)))))

I'm attaching the entire MSE file of the Metamodel for more info (there are other cases where ref: is Number, etc.
FamixTypeScriptMetamodel.mse.txt

#isPrimitive #isRoot etc.

Should they be moved up to Famix3Type?

Also: #descriptionOf:ifPresent:ifAbsent: --> #fmTypeOf:ifPresent:ifAbsent:

⚠️ deprecate the old method, do not simply remove it.

See #28 conversation

The FM3Type has a Set to hold the traits.
Whereas it is good as a first solution, it would be nice to use FMMultiValue as we did for packages etc.

The idea is to implement a method/attribute named users in FM3Trait that will be the opposite of the FM3Type>>traits

We should release a 2.0.0 version since the current dev version, used in Famix, has traits and Json exporter.
So it will be easier in the future to manage Fame evolution.
What is your opinion @ClotildeToullec?

I found a case (PowerBuilder) were this cache was causing bugs
Is it really needed ?

To avoid properties evaluated as nil when it does not make sense, or nil checks like

isClassSide
    ^ classSide ifNil: [ ^ false ]

---> create FmxMBBehavior>#property:type:defaultValue:

It is impossible to have only the traits used directly (or locally) via an FM3Trait. That is to say that the "traits" method of an FM3Trait returns its entire trait usage chain.

For example, for the FM3Trait: FAST-Core-Model.TNullPointerLiteral, its method returns 4 traits going back to Moose-Query.TEntityMEtaLevelDependency.

While the equivalent Pharo trait, via "implementingClass traits", returns only the direct FASTTLiteral trait. But be careful, it returns a Pharo trait and not an FM3Trait.

In conclusion, the problem is not to be able to access the FM3Traits used by another FM3Trait without going through the Pharo trait and using a hack.

I did some tests in an image and I found this:

FamixJavaEntity allSubInstances size. "1.941.951"

FMSlotMultivalueLink allInstances size. "3.454.420"

(FMSlotMultivalueLink allInstances select: #isEmpty) size. "2.411.735"

So I have an image with 2 millions entities. In total they have 3.5millions collections to point to other entities. But out of those, 2.4 millions are empty which means we have collections taking up space for nothing.

My idea is to improve the FMMany so that it does not initialize itself with a FMSlotMultivalueLink but with a read only singleton of a Null entity that would get replaced the first time we add an element. Like this we would get only one instance in the image.

See discussion in moosetechnology/Famix#590.

It can not be exported when MooseUnavailableMetric is an attribute

FMMetaMetaModel does not allows new, arguing that it must be accessed through a singleton "default".
This means that we cannot really define new meta-meta models.
We should think in an other way to deal with the single-metameta-model. Before there was a meta repository that i see has been deprecated. We should discuss on how to solve this problem

FM3Constants is used as shown in the image.

MetaModel / MetaMetaModel and ModelExporter. Meaning that our 3 levels of Meta are all tangled with a specific model.

During the initialization of a FMMetaMetaModel we are executing an "updateCache" method that does as follow at the level of the FMMetaModel:
updateCache
nameDict := (FM3Constant constants collect: [ :const | const name asString -> const ]) asDictionary.
typeDict := (FM3Constant constants collect: [ :const | const class -> const ]) asDictionary.
self elements do: [ :each | self updateCacheWith: each ].

This couple the FM3 specific meta model to the metaMetaModel.

When exporting, the current behavior is:

• Begin entity = print "FM3" : "..."
• Serial = print "id" : aNumber,
• Print properties

The issue is occurring when an entity has no properties: the coma after the id number is not followed by anything before closing the object. That is not correct in JSON.

During the exporting of a metamodel, whatever object in moose properties that do not belongs to the meta model and is not a simple object (string / bool / etc) is ignored without warning nor error.

It may be a good behaviour for some usages, but we should allow the activation of exceptions (or deactivation), for the process of development, to ensure that we can understand what is not being exported, when and why.

It could be also nice to article some secondary serializer for those objects that we cannot export with MSE such as Fuel or Ston. Like this we can keep our "boundary" objects (such as an smacc ast )

It is impossible to call FMMetaModel>>descriptionOf: on an FM3Trait because FM3Trait are not present in classDict (FMMetaModel instance variables), unlike FM3Class.

FMMultivalueLink should be tested with basic Collection API like collect:, select:, etc.