Hi!
Just to share what I am currently seeing while attending a conference
on Model transformation.
People seems to enjoy the select and collect operations for sets in OCL.
For example, this is what I see on a projected slide:
context CD:Class
def allSuperclasses: self.parents->union(self.superclasses->collect(c
| c.allSuperclasses)->flatten())
Apparently, the fact that you can combine these constructs is
innovative...
Maybe in the future, we should try to target ICMT and other model-like
conference.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
- Added new Mondrian features in FAMIXFoldergroup
- new version of FAMIXFile* classes:
- added entities in FAMIXAbstractFile: any file should knows about
the entities it defines
- added new nagivation pragmas
- convenient methods for testing: ifFolder: ifFolderIfNotFolder: ...
Cheers,
Alexandre
Dear List,
Currently, there is no connection between instances of FAMIXFile/
Folder and entities that are supposed to be defined in (e.g., a .java
files and a class, a .c file and an instance of CAModule).
I extended FAMIXAbstractFile with definedEntities to have:
FAMIXNamedEntity subclass: #FAMIXAbstractFile
instanceVariableNames: 'belongsTo entities'
Then I was unsure whether Fame should to be used. Should 'entities'
refers to an ordered collection or a FMMultivalueLink. What will be
the opposite then? sourceAnchor could be a good candidate, but I am
unsure. For now, I did without Fame.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Dear Moosers
As you may know, identity hashes attributed by the virtual machine
ranges up to 4096. This may be problematic when storing objects in a
dictionary. We often have to deal with high number of entities, and
using dictionary is out of question for performance reason.
One solution (inspired from Lukas) would be to use the ID that each
MooseEntity has instead of the hash.
I will try to see whether hash can be overriden in MooseEntity to
return its ID instead.
Will let you know.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
- The MonticelloImporter now merge classes and metaclasses
- Caches have been added to OB nodes for the moose browser. Necessary
for a real use
- FAMIXFolder>>filesGroup added
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Just to announce that external class extensions are now correctly
imported in the last version of Moose.
To explain: if you import a package A which made class extensions to
classes of a package external to the import (say Kernel), such
extensions were not taken into account.
Only class extensions made to classes of package A were taken into
account before.
Also got the count of failing tests down to 2 and of error test down
to 1.
--
Simon
hi all
I would like to know the stability of PhMondrian.
Apparently Jannik got problem and had to disable caches.
What is your experience with it.
In particular I would also like to know whether PackageBlueprint works
on
sqMoose. Would be nice to rescue this nice visualization.
In addition is distribution map (the real version) working on PhMoose
or PhMondrian?
Stef
Dear List,
FAMIXNamedEntity has a variables named receivingInvocations.
FAMIXBehaviouralEntity, a subclass of FAMIXNamedEntity, has a variable
incomingInvocations
What is the difference between the two? Leftover of Famix2 ?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Guys,
I looked a bit in more detail at the class extensions problem. Here I
bring a bit more to the discussion table.
I attach a Snaut screenshot of an analysis session of Hapax + Code Foo.
(seems attachment is too big for the mailinglist so here's a link: http://www.inf.unisi.ch/phd/lungu/files/ClassExtensionsInMoose.png)
The panel on the right is the detail of the 91 invocations abstracted
in the high-level dependency between Hapax Development and Visual
Works. To the right of every method which is extended in a different
package thabn Base VisualWorks you can see that package. What you will
see is that althoug most of those dependencies are defined in othe
packages than VisualWorks Base they still are abstracted in the
relationship between Hapax and VisualWorks base. You will see that
there is a dependency between hapax and Number>>pythag: which methoid
is defined in Hapax itself.
The reason is the following.
A method, even when it is an extension (isExtension is True) belongsTo
a class. And the class, logically, belongs to the namespace where it
was initially defined and is, logically, packaged in the package it
was initially defined in. When I compute the high-level depedencies in
softwarenaut i aggregate them from methods to classes and from there
up along the namespace of package hierarchy. Since the extended
methods are placed in their original classes, I end up with
dependencies between the wrong packages.
The high-level dependencies in softwarenaut are wrong because the
model can not express the existence of class extensions.
I can see two solutions:
- we introduce a FAMIXClassExtension as an explicit entity which is a
class which has a reference to the extended class. maybe we can even
introduce a new relationship which is Class Extension.
- we piggyback the class extensions on top of the classes in a similar
way the metaclasses are implemented. In our example, for Collection we
would define a Collection class in CodeFoo, SqueakExtensions, EyeSee
and ech one of these would only contain the methods that it defines.
I am interested if anybody else is interested in this. And I want to
hear your opinions.
Cheers,
Mircea.
