8 Apr
2009
8 Apr
'09
1:30 p.m.
Dear List,
I am currently working on a C importer based on srcML output. I
created an extension of FAMIX3 (I am working with Pharo) since FAMIX3
did not express procedural languages.
Essentially, 4 classes defines this extension:
- CAFunction subclass of FAMIXBehaviouralEntity
- CAInclue subclass of FAMIXAssociation
- CAModule subclass of FAMIXScopingEntity
- CAVariable subclass of FAMIXGlobalVariable
An instance of CAModule is intended to describe a C Module, instance
being generated from a C file. I think this should be the right way
to do.
On the other hand, there are FAMIXFolder and FAMIXFile. Ideally, a C
file should be seen as a file _and_ as a module. The class FAMIXFile
contains useful methods, that I would like to use on a CAModule. But
having one instance of CAModule and one instance of FAMIXFile per .c
file is clearly suboptimal.
My intuitions argues for creating a trait TFAMIXFile, that will be
used by both FAMIXFile and CAModule.
Any comment on this trait?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
11 Apr
11 Apr
12:18 a.m.
Hi Alex,
I am currently working on a C importer based on srcML
output. I
created an extension of FAMIX3 (I am working with Pharo) since
FAMIX3 did not express procedural languages.
Essentially, 4 classes defines this extension:
- CAFunction subclass of FAMIXBehaviouralEntity
You should use the FAMIXFunction. I know that Simon removed it, but it
should be there in the Core.
- CAInclue subclass of FAMIXAssociation
Cool.
- CAModule subclass of FAMIXScopingEntity
Hmm. Isn't a CAModule the same as FAMIXPackage?
- CAVariable subclass of FAMIXGlobalVariable
What is the difference between the two?
An instance of CAModule is intended to describe a C
Module, instance
being generated from a C file. I think this should be the right way
to do.
On the other hand, there are FAMIXFolder and FAMIXFile. Ideally, a C
file should be seen as a file _and_ as a module. The class FAMIXFile
contains useful methods, that I would like to use on a CAModule. But
having one instance of CAModule and one instance of FAMIXFile per .c
file is clearly suboptimal.
FAMIXFile and Folder denote structural things, and have no semantics.
CAModule has semantics in a similar way a Package has. If you want to
attach a file to it, just have the sourceAnchor point to the file.
My intuitions argues for creating a trait TFAMIXFile,
that will be
used by both FAMIXFile and CAModule.
Any comment on this trait?
Cheers,
Alexandre
Cheers,
Doru
--
www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of
problem understanding."
11:15 a.m.
Hi Doru,
We point here the finger on a slightly bigger problem, scalability.
Currently CAVariable has no instance variable. However it inherits 14
instance variables from the FAMIX framework.
CAModule defines 7 variables, and inherits 17 variables.
Before to have CA* classes an extension of FAMIX, loading the complete
linux kernel produced a squeak image of ~ 500 Mb. I haven't tried
since CA* classes are subclass of FAMIX, but an explosion in size may
waste the party.
By having such subclasses, I can always to change, even temporarily,
the superclass to meet extreme scalability requirement.
Right.
Thanks Doru,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
You should use the FAMIXFunction. I know that Simon
removed it, but
it should be there in the Core.
I do not remember, maybe I was the one who removed it on a
misunderstanding.
- CAModule
subclass of FAMIXScopingEntity
Hmm. Isn't a CAModule the same as FAMIXPackage?
- CAVariable subclass of FAMIXGlobalVariable
What is the difference between the two? An instance of
CAModule is intended to describe a C Module,
instance being generated from a C file. I think this should be the
right way to do.
On the other hand, there are FAMIXFolder and FAMIXFile. Ideally, a
C file should be seen as a file _and_ as a module. The class
FAMIXFile contains useful methods, that I would like to use on a
CAModule. But having one instance of CAModule and one instance of
FAMIXFile per .c file is clearly suboptimal.
FAMIXFile and Folder denote structural things, and have no
semantics. CAModule has semantics in a similar way a Package has. If
you want to attach a file to it, just have the sourceAnchor point to
the file.
1:51 p.m.
Hi Alex,
In VW, we dealt with the state explosion problem by delegating state
access from AbstractEntity to EntityState. There are two subclasses of
this state:
- DefaultEntityState implements a dictionary for instance variables
used for caching or for properties (like NOM).
- MinimalEntityState implements nothing.
We also combined the state access with lazy initializers.
The idea is that the main model is implemented via instance variables,
but all the rest are delegated to the EntityState. In particular, for
caches or for derived attributes you do not always want to allocate an
instance variable. So, for example FAMIXGlobalVariable might not need
a comments iv, or an incomingInvocations.
Another useful usage of the EntityState implementation is that we can
easily extend the state of an entity from other packages. At least in
VW, the there is no good support for state extension so this way of
extending is the only possibility.
Cheers,
Doru
On 11 Apr 2009, at 11:15, Alexandre Bergel wrote:
Hi Doru,
We point here the finger on a slightly bigger problem, scalability.
Currently CAVariable has no instance variable. However it inherits
14 instance variables from the FAMIX framework.
CAModule defines 7 variables, and inherits 17 variables.
Before to have CA* classes an extension of FAMIX, loading the
complete linux kernel produced a squeak image of ~ 500 Mb. I haven't
tried since CA* classes are subclass of FAMIX, but an explosion in
size may waste the party.
By having such subclasses, I can always to change, even temporarily,
the superclass to meet extreme scalability requirement.
Right.
Thanks Doru,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"To lead is not to demand things, it is to make them happen."
You should use the FAMIXFunction. I know that
Simon removed it, but
it should be there in the Core.
I do not remember, maybe I was the one who removed it on a
misunderstanding.
-
CAModule subclass of FAMIXScopingEntity
Hmm. Isn't a CAModule the same as FAMIXPackage?
- CAVariable subclass of FAMIXGlobalVariable
What is the difference between the two? An
instance of CAModule is intended to describe a C Module,
instance being generated from a C file. I think this should be
the right way to do.
On the other hand, there are FAMIXFolder and FAMIXFile. Ideally, a
C file should be seen as a file _and_ as a module. The class
FAMIXFile contains useful methods, that I would like to use on a
CAModule. But having one instance of CAModule and one instance of
FAMIXFile per .c file is clearly suboptimal.
FAMIXFile and Folder denote structural things, and have no
semantics. CAModule has semantics in a similar way a Package has.
If you want to attach a file to it, just have the sourceAnchor
point to the file.
13 Apr
13 Apr
11:30 a.m.
This is what I guess yes. MooseEntity defines a variable state. This
is what you refer to.
But there are still many iv in the hierarchy. It is early to talk
about design now. Soon I will try to load Linux into Moose. Problems
will appear by themselves.
Cheers,
Alexandre
On 11 Apr 2009, at 13:51, Tudor Girba wrote:
Hi Alex,
In VW, we dealt with the state explosion problem by delegating state
access from AbstractEntity to EntityState. There are two subclasses
of this state:
- DefaultEntityState implements a dictionary for instance variables
used for caching or for properties (like NOM).
- MinimalEntityState implements nothing.
We also combined the state access with lazy initializers.
The idea is that the main model is implemented via instance
variables, but all the rest are delegated to the EntityState. In
particular, for caches or for derived attributes you do not always
want to allocate an instance variable. So, for example
FAMIXGlobalVariable might not need a comments iv, or an
incomingInvocations.
Another useful usage of the EntityState implementation is that we
can easily extend the state of an entity from other packages. At
least in VW, the there is no good support for state extension so
this way of extending is the only possibility.
Cheers,
Doru
On 11 Apr 2009, at 11:15, Alexandre Bergel wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Doru,
We point here the finger on a slightly bigger problem, scalability.
Currently CAVariable has no instance variable. However it inherits
14 instance variables from the FAMIX framework.
CAModule defines 7 variables, and inherits 17 variables.
Before to have CA* classes an extension of FAMIX, loading the
complete linux kernel produced a squeak image of ~ 500 Mb. I
haven't tried since CA* classes are subclass of FAMIX, but an
explosion in size may waste the party.
By having such subclasses, I can always to change, even
temporarily, the superclass to meet extreme scalability requirement.
Right.
Thanks Doru,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"To lead is not to demand things, it is to make them happen."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev You should use the FAMIXFunction. I know that
Simon removed it,
but it should be there in the Core.
I do not remember, maybe I was the one who removed it on a
misunderstanding.
-
CAModule subclass of FAMIXScopingEntity
Hmm. Isn't a CAModule the same as FAMIXPackage?
- CAVariable subclass of FAMIXGlobalVariable
What is the difference between the two? An
instance of CAModule is intended to describe a C Module,
instance being generated from a C file. I think this should be
the right way to do.
On the other hand, there are FAMIXFolder and FAMIXFile. Ideally,
a C file should be seen as a file _and_ as a module. The class
FAMIXFile contains useful methods, that I would like to use on a
CAModule. But having one instance of CAModule and one instance of
FAMIXFile per .c file is clearly suboptimal.
FAMIXFile and Folder denote structural things, and have no
semantics. CAModule has semantics in a similar way a Package has.
If you want to attach a file to it, just have the sourceAnchor
point to the file.
15 Apr
15 Apr
11:44 p.m.
Hi Alex,
This is what I guess yes. MooseEntity defines a
variable state. This
is what you refer to.
Yes.
But there are still many iv in the hierarchy.
Sure. The idea is that for the ivs that go with required properties,
you do not want to rely on an extra indirection, because they will be
populated anyway. The gain comes from making the derived ones and the
cached ones being implemented in this dictionary.
It is early to talk about design now. Soon I will try
to load Linux
into Moose. Problems will appear by themselves.
It is not really early because we already went through it several
times :).
Cheers,
Doru
Cheers,
Alexandre
On 11 Apr 2009, at 13:51, Tudor Girba wrote:
--
www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
Hi Alex,
In VW, we dealt with the state explosion problem by delegating
state access from AbstractEntity to EntityState. There are two
subclasses of this state:
- DefaultEntityState implements a dictionary for instance variables
used for caching or for properties (like NOM).
- MinimalEntityState implements nothing.
We also combined the state access with lazy initializers.
The idea is that the main model is implemented via instance
variables, but all the rest are delegated to the EntityState. In
particular, for caches or for derived attributes you do not always
want to allocate an instance variable. So, for example
FAMIXGlobalVariable might not need a comments iv, or an
incomingInvocations.
Another useful usage of the EntityState implementation is that we
can easily extend the state of an entity from other packages. At
least in VW, the there is no good support for state extension so
this way of extending is the only possibility.
Cheers,
Doru
On 11 Apr 2009, at 11:15, Alexandre Bergel wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Doru,
--
www.tudorgirba.com
"To lead is not to demand things, it is to make them happen."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev You should use the FAMIXFunction. I know that
Simon removed it,
but it should be there in the Core.
I do not remember, maybe I was the one who removed it on a
misunderstanding.
> - CAModule subclass of FAMIXScopingEntity
Hmm. Isn't a CAModule the same as FAMIXPackage?
> - CAVariable subclass of FAMIXGlobalVariable
What is the difference between the two?
We point here the finger on a slightly bigger problem, scalability.
Currently CAVariable has no instance variable. However it inherits
14 instance variables from the FAMIX framework.
CAModule defines 7 variables, and inherits 17 variables.
Before to have CA* classes an extension of FAMIX, loading the
complete linux kernel produced a squeak image of ~ 500 Mb. I
haven't tried since CA* classes are subclass of FAMIX, but an
explosion in size may waste the party.
By having such subclasses, I can always to change, even
temporarily, the superclass to meet extreme scalability requirement.
> An instance of CAModule is intended to
describe a C Module,
> instance being generated from a C file. I think this should be
> the right way to do.
> On the other hand, there are FAMIXFolder and FAMIXFile. Ideally,
> a C file should be seen as a file _and_ as a module. The class
> FAMIXFile contains useful methods, that I would like to use on a
> CAModule. But having one instance of CAModule and one instance
> of FAMIXFile per .c file is clearly suboptimal.
FAMIXFile and Folder denote structural things, and have no
semantics. CAModule has semantics in a similar way a Package has.
If you want to attach a file to it, just have the sourceAnchor
point to the file.
Right.
Thanks Doru,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5731
days inactive
5738
days old
5 comments
2 participants
participants (2)
-
Alexandre Bergel -
Tudor Girba