18 Oct
2007
18 Oct
'07
2:54 p.m.
Please find attached bugs in FAMIX 2.2
- Chronia.CvsFileVersion.comment has type Smalltalk.Core.Text instead of
primitive String
- Chronia.CvsFileVersion.timestamp has type Smalltalk.Core.Timestamp instead
of some primitive
- Chronia.Author has both name and Name as property, which fucks up code
generation
- Smalltalk.CvsModelRoot should be in package Chronia
- Smalltalk.Hapax package should be top level, not nested
- Smalltalk.Dude package should be top level, not nested
- Opposites do not match: DynaMoose.Alias.variable
- Opposites do not match: FAMIX.Method.activation
- Container must be single-values: Moose.Model.entity
- Opposites do not match: Moose.Model.mooseModel
- Container must be single-values: FAMIX.Package.definedClass
- Missing type: Chronia.Commit.startTime
- Missing type: Chronia.Commit.endTime
- Opposites do not match: FAMIX.AbstractStructuralEntity.accessedByList
- Opposites do not match: DynaMoose.Activation.argument
- May not have more than one container: FAMIX.Namespace
- Container must be single-values: FAMIX.Namespace.class
- Container must be single-values: FAMIX.Namespace.namespace
- Opposites do not match: FAMIX.InheritanceDefinition.superclass
- Opposites do not match: FAMIX.InheritanceDefinition.subclass
- May not have more than one container: FAMIX.Class
- Container must be single-values: FAMIX.Class.attribute
- Opposites do not match: FAMIX.Class.incomingInheritance
- Opposites do not match: FAMIX.Class.accessedByList
- Opposites do not match: FAMIX.Class.outgoingInheritance
- Container must be single-values: FAMIX.Class.method
cheers,
AA
19 Oct
19 Oct
8:50 a.m.
On 18 oct. 07, at 14:54, A. Kuhn wrote:
Please find attached bugs in FAMIX 2.2
- Chronia.CvsFileVersion.comment has type Smalltalk.Core.Text
instead of
primitive String
- Chronia.CvsFileVersion.timestamp has type
Smalltalk.Core.Timestamp instead
of some primitive
- Chronia.Author has both name and Name as property, which fucks up
code
generation
- Smalltalk.CvsModelRoot should be in package Chronia
- Smalltalk.Hapax package should be top level, not nested
- Smalltalk.Dude package should be top level, not nested
- Opposites do not match: DynaMoose.Alias.variable
- Opposites do not match: FAMIX.Method.activation
- Container must be single-values: Moose.Model.entity
- Opposites do not match: Moose.Model.mooseModel
- Container must be single-values: FAMIX.Package.definedClass
What exactly means this sentence?
what is container package or namespace?
I do not remember how class extensions are modeled but this means
that we have a home package and severa extending packages.
- Missing type: Chronia.Commit.startTime
- Missing type: Chronia.Commit.endTime
- Opposites do not match:
FAMIX.AbstractStructuralEntity.accessedByList
- Opposites do not match: DynaMoose.Activation.argument
- May not have more than one container: FAMIX.Namespace
- Container must be single-values: FAMIX.Namespace.class
- Container must be single-values:
FAMIX.Namespace.namespace
- Opposites do not match: FAMIX.InheritanceDefinition.superclass
- Opposites do not match: FAMIX.InheritanceDefinition.subclass
I do not understand
why subclass and superclass would have a problem
in FAMIX
- May not have more than one container: FAMIX.Class
- Container must be single-values: FAMIX.Class.attribute
- Opposites do not match: FAMIX.Class.incomingInheritance
- Opposites do not match: FAMIX.Class.accessedByList
- Opposites do not match: FAMIX.Class.outgoingInheritance
Could we change the name outgoingInhertiance because this is
terrible. Consistent is good but not at that price.
- Container must be single-values: FAMIX.Class.method
cheers,
AA
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:14 a.m.
- Container
must be single-values: FAMIX.Package.definedClass
What exactly means this sentence?
what is container package or namespace?
I do not remember how class extensions are modeled but this means
that we have a home package and severa extending packages. - Opposites do
not match: FAMIX.InheritanceDefinition.superclass
- Opposites do not match: FAMIX.InheritanceDefinition.subclass
I do not understand why subclass and superclass would have a problem
in FAMIX - Opposites do
not match: FAMIX.Class.incomingInheritance
- Opposites do not match: FAMIX.Class.outgoingInheritance
Could we change the name outgoingInhertiance because this is
terrible. Consistent is good but not at that price. > - Container must be single-values:
FAMIX.Class.method
>
> cheers,
> AA
>
>
12:29 p.m.
On (19/10/07 09:14), Adrian Kuhn wrote:
generalizing...?
specializing...?
From: Adrian Kuhn <akuhn(a)gmx.ch>
To: Related to the development of Moose and other related tools
<moose-dev(a)iam.unibe.ch>ch>,
Stéphane Ducasse <stephane.ducasse(a)univ-savoie.fr>
Subject: [Moose-dev] Re: Bug in FAMIX 2.2
Date: Fri, 19 Oct 2007 09:14:56 +0200
the constraint is
EMOF.Class.allAttributes.count( p | p.isContainer ) <= 1
we best introduce drived owingPackage and ownedPackages to fix that
I guess this is a type in the annotations.
Without looking at the FAMIX2.2 specification, just of the top of my
head, if superclass and subclass are defined as opposites in the
inheritance definition, this is a wrong usage of opposite. Opposite is
used as such in mse:
(MSE.Class (id: 1 )
(.. (MSE.Property (id: 2)
(opposite (idref: 4))
(type (idref: 3))
...)))
(MSE.Class (id: 3 )
(.. (MSE.Property (id: 4)
(opposite (idref: 2))
(type (idref: 1))
...)))
As you can see, the type of the opposite is always the Class in which
the "opposited: property is embedded. Which doesn't match for those 2
properties, since they are embedded in InheritanceDefinition, not in
Class.
-
Container must be single-values: FAMIX.Package.definedClass
What exactly means this sentence?
what is container package or namespace?
I do not remember how class extensions are modeled but this means
that we have a home package and severa extending packages. -
Opposites do not match: FAMIX.InheritanceDefinition.superclass
- Opposites do not match: FAMIX.InheritanceDefinition.subclass
I do not understand why subclass and superclass would have a problem
in FAMIX - Opposites do not match:
FAMIX.Class.incomingInheritance
- Opposites do not match: FAMIX.Class.outgoingInheritance
Could we change the name outgoingInhertiance because this is
terrible. Consistent is good but not at that price. > - Container must be single-values:
FAMIX.Class.method
>
> cheers,
> AA
>
>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
1:24 p.m.
Toon, your are right.
So bug not present in 3.0 then.
AA
On 19 Oct 2007, at 12:29 , Toon Verwaest wrote:
On (19/10/07 09:14), Adrian Kuhn wrote:
generalizing...?
specializing...?
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
From: Adrian Kuhn <akuhn(a)gmx.ch>
To: Related to the development of Moose and other related tools
<moose-dev(a)iam.unibe.ch>ch>,
Stéphane Ducasse <stephane.ducasse(a)univ-savoie.fr>
Subject: [Moose-dev] Re: Bug in FAMIX 2.2
Date: Fri, 19 Oct 2007 09:14:56 +0200
the constraint is
EMOF.Class.allAttributes.count( p | p.isContainer ) <= 1
we best introduce drived owingPackage and ownedPackages to fix that
I guess this is a type in the annotations.
Without looking at the FAMIX2.2 specification, just of the top of my
head, if superclass and subclass are defined as opposites in the
inheritance definition, this is a wrong usage of opposite. Opposite is
used as such in mse:
(MSE.Class (id: 1 )
(.. (MSE.Property (id: 2)
(opposite (idref: 4))
(type (idref: 3))
...)))
(MSE.Class (id: 3 )
(.. (MSE.Property (id: 4)
(opposite (idref: 2))
(type (idref: 1))
...)))
As you can see, the type of the opposite is always the Class in which
the "opposited: property is embedded. Which doesn't match for those 2
properties, since they are embedded in InheritanceDefinition, not in
Class.
-
Container must be single-values: FAMIX.Package.definedClass
What exactly means this sentence?
what is container package or namespace?
I do not remember how class extensions are modeled but this means
that we have a home package and severa extending packages. -
Opposites do not match: FAMIX.InheritanceDefinition.superclass
- Opposites do not match: FAMIX.InheritanceDefinition.subclass
I do not understand why subclass and superclass would have a problem
in FAMIX - Opposites do not match:
FAMIX.Class.incomingInheritance
- Opposites do not match: FAMIX.Class.outgoingInheritance
Could we change the name outgoingInhertiance because this is
terrible. Consistent is good but not at that price. > - Container must be single-values:
FAMIX.Class.method
>
> cheers,
> AA
>
>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
20 Oct
20 Oct
10:23 a.m.
Without looking at the FAMIX2.2 specification, just of the top of my
head, if superclass and subclass are defined as opposites in the
inheritance definition, this is a wrong usage of opposite. Opposite is
used as such in mse:
(MSE.Class (id: 1 )
(.. (MSE.Property (id: 2)
(opposite (idref: 4))
(type (idref: 3))
...)))
(MSE.Class (id: 3 )
(.. (MSE.Property (id: 4)
(opposite (idref: 2))
(type (idref: 1))
...)))
As you can see, the type of the opposite is always the Class in which
the "opposited: property is embedded. Which doesn't match for those 2
properties, since they are embedded in InheritanceDefinition, not in
Class.
I see.
Adrian how do you detect the problems? running an OCL constraints
interpreter?
this is good that you use now constraints.
>>> - Opposites do not match: FAMIX.Class.incomingInheritance
>>> - Opposites do not match: FAMIX.Class.outgoingInheritance
>>
>> Could we change the name outgoingInhertiance because this is
>> terrible. Consistent is good but not at that price.
>
> generalizing...?
> specializing...?
superclass, subclass :)
> - Container must be single-values:
FAMIX.Class.method
>
> cheers,
> AA
>
>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
1:42 p.m.
On 20 Oct 2007, at 10:23 , Stéphane Ducasse wrote:
I see.
Adrian how do you detect the problems? running an OCL constraints
interpreter?
this is good that you use now constraints.
Zuviel der Ehre :)
Its all hardcoded right now, just hacked in the constraints of EMOF
that apply to the subset we actually use (see http://
smallwiki.unibe.ch/moose/mse/fm3meta-metamodel)
For Smalltalk, there is an unused Constraint class, which duplicates
RB's Condition class, that could be used to write model constraints,
written in Smalltalk and looking like OCL :)
Would be nice to do.
cheers,
AA
6281
days inactive
6283
days old
6 comments
4 participants
participants (4)
-
A. Kuhn -
Adrian Kuhn -
Stéphane Ducasse -
Toon Verwaest