FamixAttribute Object.DependentsFields is duplicated by importer (famix2/famix3)

[moosetechnology]

FamixAttribute Object.DependentsFields is duplicated by importer (famix2/famix3)

[seandenigris]

Reported by tudor.girba on 2009-08-02 00:17:58

• Labels added: Component-Famix

[seandenigris]

FamixPropertiesTest >>testNoDuplicatesOfClassVariables exposes the problem

Reported by tudor.girba on 2009-09-20 17:00:41

[seandenigris]

Reported by simon.denier on 2009-12-03 13:35:15

• Status changed: Accepted

[seandenigris]

All FamixPropertiesTest (including testNoDuplicatesOfClassVariables and testClassAttributes)
work properly now, 
so I believe this issue is fixed.

I will mark it accordingly and we can reopen it if we need to.

Reported by tudor.girba on 2009-12-29 01:45:50

• Status changed: Fixed
• Labels added: Milestone-4.0

[seandenigris]

They dont in my image, and are still marked as expected failures.

Reported by simon.denier on 2010-01-13 18:04:23

• Status changed: Accepted
• Labels added: Platform-Pharo
• Labels removed: Platform-Squeak

[seandenigris]

Almost found it:

In SmalltalkIMporter>>createClass:
we have
       "with latest pharo class classVar = class class classVar so we should not need
that anymore"
    aClass isMeta 
        ifTrue: [aClass soleInstance classVarNames
                do: [:eachClassVarName | self ensureClassVarAttribute: eachClassVarName for: aClass]]
        ifFalse: [ aClass classVarNames
                do: [:eachClassVarName | self ensureClassVarAttribute: eachClassVarName for: aClass]]].

The second line seems harmful as it will import class var both in the class and in
the metaclass.
We can comment out the second line as such var should be imported one time.

Another related bug (which does not appear with the above code): creation of FamixAccess
needs to resolve 
the variable. In the case of a shared variable, it may not look in the wrong scope
in the importer. Basically:
- a shared variable is registered as a an attribute of a FamixClass 'Zorg'
- but is registered in the scope of 'Zorg class'
(with the above, it seems to be registered both in Zorg and Zorg class scope, so one
will always be found)
so an access to a shared variable from instance side looks into the instance scope
and not the class scope 
where the shared is registered

Reported by cy.delaunay on 2010-01-22 16:15:52

[seandenigris]

Reported by simon.denier on 2010-01-29 17:47:36

• Status changed: Fixed

[seandenigris]

Excellent!

Reported by tudor.girba on 2010-01-29 20:01:20