17 Feb
2010
17 Feb
'10
1:46 p.m.
I have simulated a remove cycle process.
Manually I move some elements in a mooseModel of Moose.
To remove all cycles in Moose, my conclusions are:
=====
extend method>>
Smalltalk::FAMIXClass.browseSource() in Moose-Finder.
extend method>> Smalltalk::FAMIXMethod.browseSource() in Moose-Finder.
move class>> Smalltalk::MPImportSTCommand in Moose-Wizard.
move class>> Smalltalk::MPImportJavaSourceFilesWithInFusionCommand in Moose-Wizard.
extend method>> Smalltalk::FAMIXNamedEntity.isAbstract() in Famix-Extensions.
extend method>> Smalltalk::FAMIXNamedEntity.isAbstract:(Object) in
Famix-Extensions.
extend method>> Smalltalk::FAMIXClass.isAbstract() in Famix-Extensions.
extend method>> Smalltalk::CompiledMethod.mooseName() in Famix-Implementation.
extend method>> Smalltalk::CompiledMethod.mooseNameWithScope:(Object) in
Famix-Implementation.
remove reference>> checkClass: refers to MooseModel.
extend method>> Smalltalk::MooseModel.mseExportationTest() in
Moose-SmalltalkImporterTests.
move class>> Smalltalk::MooseScripts in Moose-SmalltalkImporter.
remove method>> Smalltalk::FAMIXClass.ascendingPathTo:(Object).
extend method>> Smalltalk::FAMIXPackage.definedMethods() in Famix-Extensions.
extend method>> Smalltalk::FAMIXPackage.extendedClasses() in Famix-Extensions.
extend method>> Smalltalk::FAMIXPackage.extendedClassesGroup() in Famix-Extensions.
extend method>> Smalltalk::FAMIXPackage.extensionClasses() in Famix-Extensions.
extend method>> Smalltalk::FAMIXPackage.extensionClassesGroup() in
Famix-Extensions.
extend method>> Smalltalk::FAMIXPackage.extensionMethods() in Famix-Extensions.
extend method>> Smalltalk::FAMIXPackage.localMethods() in Famix-Extensions.
extend method>> Smalltalk::FAMIXPackage.localClasses() in Famix-Extensions.
extend method>> Smalltalk::FAMIXPackage.localClassesGroup() in Famix-Extensions.
=====
Is it ok for you ?
Cheers
Jannik
17 Feb
17 Feb
2:40 p.m.
Can you provide more incentive about those methods? Why do they create a cycle. And if
they create some, perhaps their implementation needs to be changed.
On 17 févr. 2010, at 13:46, Laval Jannik wrote:
--
Simon
> extend method>>
Smalltalk::FAMIXNamedEntity.isAbstract() in Famix-Extensions.
> extend method>> Smalltalk::FAMIXNamedEntity.isAbstract:(Object) in
Famix-Extensions.
> extend method>> Smalltalk::FAMIXClass.isAbstract() in Famix-Extensions.
extend method>> Smalltalk::FAMIXPackage.definedMethods() in Famix-Extensions.
extend method>> Smalltalk::FAMIXPackage.extendedClasses() in Famix-Extensions.
extend method>> Smalltalk::FAMIXPackage.extendedClassesGroup() in
Famix-Extensions.
extend method>> Smalltalk::FAMIXPackage.extensionClasses() in Famix-Extensions.
extend method>> Smalltalk::FAMIXPackage.extensionClassesGroup() in
Famix-Extensions.
extend method>> Smalltalk::FAMIXPackage.extensionMethods() in Famix-Extensions.
extend method>> Smalltalk::FAMIXPackage.localMethods() in Famix-Extensions.
extend method>> Smalltalk::FAMIXPackage.localClasses() in Famix-Extensions.
extend method>> Smalltalk::FAMIXPackage.localClassesGroup() in Famix-Extensions.
=====
Is it ok for you ?
Cheers
Jannik
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
3:09 p.m.
For sure, I can :),
But maybe you want a dsm to see cycles ?
To do simple, isAbstract is defined in Famix-Core, but all other isSomething are defined
in FamixExtensions.
It seems to be correct to move it with other test methods.
For the ret, maybe we could do this:
>> extend method>>
Smalltalk::FAMIXPackage.definedMethods() in Famix-Extensions.
it is an alias of self
methods, it should be in Famix-Implementations
>> extend method>>
Smalltalk::FAMIXPackage.localClasses() in Famix-Extensions.
it is an alias of self
classes, it should be in Famix-Implementations
>> extend method>>
Smalltalk::FAMIXPackage.extendedClasses() in Famix-Extensions.
>> extend method>> Smalltalk::FAMIXPackage.extendedClassesGroup() in
Famix-Extensions.
>> extend method>> Smalltalk::FAMIXPackage.extensionClasses() in
Famix-Extensions.
>> extend method>> Smalltalk::FAMIXPackage.extensionClassesGroup() in
Famix-Extensions.
>> extend method>> Smalltalk::FAMIXPackage.extensionMethods() in
Famix-Extensions.
>> extend method>> Smalltalk::FAMIXPackage.localMethods() in
Famix-Extensions.
>> extend method>> Smalltalk::FAMIXPackage.localClassesGroup() in
Famix-Extensions.
These methods are used by Cook, which is in Famix-Extension now.
But I will try something else.
Cheers,
Jannik
On Feb 17, 2010, at 14:40 , Simon Denier wrote:
Can you provide more incentive about those methods? Why do they create a cycle. And if
they create some, perhaps their implementation needs to be changed.
On 17 févr. 2010, at 13:46, Laval Jannik wrote:
=====
Is it ok for you ?
Cheers
Jannik
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> extend method>>
Smalltalk::FAMIXNamedEntity.isAbstract() in Famix-Extensions.
> extend method>> Smalltalk::FAMIXNamedEntity.isAbstract:(Object) in
Famix-Extensions.
> extend method>> Smalltalk::FAMIXClass.isAbstract() in Famix-Extensions.
4:07 p.m.
On 17 févr. 2010, at 15:09, Laval Jannik wrote:
For sure, I can :),
But maybe you want a dsm to see cycles ?
To do simple, isAbstract is defined in Famix-Core, but all other isSomething are defined
in FamixExtensions.
It seems to be correct to move it with other test methods.
yeah, but why does isAbstract create a cycle?
For the ret, maybe we could do this:
Jannik, if we rewrite the cook queries with the Chef API, those dependencies will
disappear right? And we can keep smalltalkish stuff in Famix-Smalltalk. I still find it
more disturbing that Cook depends on some Smalltalk stuff, and moving this stuff in
Extensions feels a bit like sweeping it under the carpet.
--
Simon
>> extend method>>
Smalltalk::FAMIXPackage.definedMethods() in Famix-Extensions.
it is an alias of
self methods, it should be in Famix-Implementations
>> extend method>>
Smalltalk::FAMIXPackage.localClasses() in Famix-Extensions.
it is an alias of self
classes, it should be in Famix-Implementations
>> extend method>>
Smalltalk::FAMIXPackage.extendedClasses() in Famix-Extensions.
>> extend method>> Smalltalk::FAMIXPackage.extendedClassesGroup() in
Famix-Extensions.
>> extend method>> Smalltalk::FAMIXPackage.extensionClasses() in
Famix-Extensions.
>> extend method>> Smalltalk::FAMIXPackage.extensionClassesGroup() in
Famix-Extensions.
>> extend method>> Smalltalk::FAMIXPackage.extensionMethods() in
Famix-Extensions.
>> extend method>> Smalltalk::FAMIXPackage.localMethods() in
Famix-Extensions.
>> extend method>> Smalltalk::FAMIXPackage.localClassesGroup() in
Famix-Extensions.
These methods are used by Cook, which is in Famix-Extension now.
But I will try something else.
5:16 p.m.
On Feb 17, 2010, at 16:07 , Simon Denier wrote:
On 17 févr. 2010, at 15:09, Laval Jannik wrote:
because it uses modifierSet:for: wich is defined in Famix-Implementation.
Famix-Implementation depends on FamixCore.
So there is a cycle.
Cheers,
Jannik
For sure, I can :),
But maybe you want a dsm to see cycles ?
To do simple, isAbstract is defined in Famix-Core, but all other isSomething are defined
in FamixExtensions.
It seems to be correct to move it with other test methods.
yeah, but why does isAbstract create a cycle?
For the ret, maybe we could do this:
Jannik, if we rewrite the cook queries with the Chef API, those dependencies will
disappear right? And we can keep smalltalkish stuff in Famix-Smalltalk. I still find it
more disturbing that Cook depends on some Smalltalk stuff, and moving this stuff in
Extensions feels a bit like sweeping it under the carpet.
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> extend method>>
Smalltalk::FAMIXPackage.definedMethods() in Famix-Extensions.
it is an alias of
self methods, it should be in Famix-Implementations
>> extend method>>
Smalltalk::FAMIXPackage.localClasses() in Famix-Extensions.
it is an alias of self
classes, it should be in Famix-Implementations
>> extend method>>
Smalltalk::FAMIXPackage.extendedClasses() in Famix-Extensions.
>> extend method>> Smalltalk::FAMIXPackage.extendedClassesGroup() in
Famix-Extensions.
>> extend method>> Smalltalk::FAMIXPackage.extensionClasses() in
Famix-Extensions.
>> extend method>> Smalltalk::FAMIXPackage.extensionClassesGroup() in
Famix-Extensions.
>> extend method>> Smalltalk::FAMIXPackage.extensionMethods() in
Famix-Extensions.
>> extend method>> Smalltalk::FAMIXPackage.localMethods() in
Famix-Extensions.
>> extend method>> Smalltalk::FAMIXPackage.localClassesGroup() in
Famix-Extensions.
These methods are used by Cook, which is in Famix-Extension now.
But I will try something else. 
7:58 p.m.
It is a bit difficult for me to judge whether these are good moves or
not. But removing cycles is important and I welcome any initiatives
that go in that direction.
Cheers,
Alexandre
On 17 Feb 2010, at 09:46, Laval Jannik wrote:
I have simulated a remove cycle process.
Manually I move some elements in a mooseModel of Moose.
To remove all cycles in Moose, my conclusions are:
=====
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
extend method>>
Smalltalk::FAMIXClass.browseSource() in Moose-Finder.
extend method>> Smalltalk::FAMIXMethod.browseSource() in Moose-
Finder.
move class>> Smalltalk::MPImportSTCommand in Moose-Wizard.
move class>> Smalltalk::MPImportJavaSourceFilesWithInFusionCommand
in Moose-Wizard.
extend method>> Smalltalk::FAMIXNamedEntity.isAbstract() in Famix-
Extensions.
extend method>> Smalltalk::FAMIXNamedEntity.isAbstract:(Object) in
Famix-Extensions.
extend method>> Smalltalk::FAMIXClass.isAbstract() in Famix-
Extensions.
extend method>> Smalltalk::CompiledMethod.mooseName() in Famix-
Implementation.
extend method>> Smalltalk::CompiledMethod.mooseNameWithScope:
(Object) in Famix-Implementation.
remove reference>> checkClass: refers to MooseModel.
extend method>> Smalltalk::MooseModel.mseExportationTest() in Moose-
SmalltalkImporterTests.
move class>> Smalltalk::MooseScripts in Moose-SmalltalkImporter.
remove method>> Smalltalk::FAMIXClass.ascendingPathTo:(Object).
extend method>> Smalltalk::FAMIXPackage.definedMethods() in Famix-
Extensions.
extend method>> Smalltalk::FAMIXPackage.extendedClasses() in Famix-
Extensions.
extend method>> Smalltalk::FAMIXPackage.extendedClassesGroup() in
Famix-Extensions.
extend method>> Smalltalk::FAMIXPackage.extensionClasses() in Famix-
Extensions.
extend method>> Smalltalk::FAMIXPackage.extensionClassesGroup() in
Famix-Extensions.
extend method>> Smalltalk::FAMIXPackage.extensionMethods() in Famix-
Extensions.
extend method>> Smalltalk::FAMIXPackage.localMethods() in Famix-
Extensions.
extend method>> Smalltalk::FAMIXPackage.localClasses() in Famix-
Extensions.
extend method>> Smalltalk::FAMIXPackage.localClassesGroup() in
Famix-Extensions.
=====
Is it ok for you ?
Cheers
Jannik
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5422
days inactive
5422
days old
5 comments
3 participants
participants (3)
-
Alexandre Bergel -
Laval Jannik -
Simon Denier