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
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
- 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.
the constraint is
EMOF.Class.allAttributes.count( p | p.isContainer ) <= 1
we best introduce drived owingPackage and ownedPackages to fix that
- 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
I guess this is a type in the annotations.
- 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...?
- Container must be single-values: FAMIX.Class.method
cheers, AA
On (19/10/07 09:14), Adrian Kuhn wrote:
From: Adrian Kuhn akuhn@gmx.ch To: Related to the development of Moose and other related tools moose-dev@iam.unibe.ch, Stéphane Ducasse stephane.ducasse@univ-savoie.fr Subject: [Moose-dev] Re: Bug in FAMIX 2.2 Date: Fri, 19 Oct 2007 09:14:56 +0200
- 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.
the constraint is
EMOF.Class.allAttributes.count( p | p.isContainer ) <= 1
we best introduce drived owingPackage and ownedPackages to fix that
- 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
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.
- 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...?
- Container must be single-values: FAMIX.Class.method
cheers, AA
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
From: Adrian Kuhn akuhn@gmx.ch To: Related to the development of Moose and other related tools moose-dev@iam.unibe.ch, Stéphane Ducasse stephane.ducasse@univ-savoie.fr Subject: [Moose-dev] Re: Bug in FAMIX 2.2 Date: Fri, 19 Oct 2007 09:14:56 +0200
- 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.
the constraint is
EMOF.Class.allAttributes.count( p | p.isContainer ) <= 1
we best introduce drived owingPackage and ownedPackages to fix that
- 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
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.
- 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...?
- Container must be single-values: FAMIX.Class.method
cheers, AA
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
-
A. Kuhn -
Adrian Kuhn -
Stéphane Ducasse -
Toon Verwaest