Hi,
Consider a piece of code:
Class MyClass { public String method A() { String a; } }
In the code above, there is a relationship between the method A and the return type String. As per my understanding, this relationship is represented with declaredType in FAMIXBehaviouralEntity.
Currently, this relationship is represented as a simple link (see FAMIXType>>declaredType) between the two entities but not as a FAMIXAssociation. Hence, when iterating over all the links/associations between two entities, we have to specifically take into account this special case. Currently, MooseChef helps in computing this information but one should know that there are other links on top of associations:
TDependencyQueries>>queryIncomingDependencies "Associations + typeDeclaractions" ^ self queryAllIncomingAssociations addAll: self queryIncomingTypeDeclarations; yourself
Another and more uniform solution would be to modify declaredType by creating an additional reference. For example, a trivial solution can be:
declaredType: aType declaredType := FMMultivalueLink on: self update: #behavioursWithDeclaredType from: self declaredType to: aType. self mooseModel ifNotNil: [self mooseModel add: (FAMIXReference new source: self; target: self declaredType) ] This change will be transparent for the current tools.
Please provide your feedback.
Usman
Well spotted!
Would it be possible to have this declaredType pointing to an association? Would it be difficult to have?
Cheers, Alexandre
Le 14 avr. 2015 à 06:41, Usman Bhatti usman.bhatti@gmail.com a écrit :
Hi,
Consider a piece of code:
Class MyClass { public String method A() { String a; } }
In the code above, there is a relationship between the method A and the return type String. As per my understanding, this relationship is represented with declaredType in FAMIXBehaviouralEntity.
Currently, this relationship is represented as a simple link (see FAMIXType>>declaredType) between the two entities but not as a FAMIXAssociation. Hence, when iterating over all the links/associations between two entities, we have to specifically take into account this special case. Currently, MooseChef helps in computing this information but one should know that there are other links on top of associations:
TDependencyQueries>>queryIncomingDependencies
"Associations + typeDeclaractions" ^ self queryAllIncomingAssociations addAll: self queryIncomingTypeDeclarations; yourself
Another and more uniform solution would be to modify declaredType by creating an additional reference. For example, a trivial solution can be:
declaredType: aType declaredType := FMMultivalueLink on: self update: #behavioursWithDeclaredType from: self declaredType to: aType. self mooseModel ifNotNil: [self mooseModel add: (FAMIXReference new source: self; target: self declaredType) ]
This change will be transparent for the current tools.
Please provide your feedback.
Usman _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Tue, Apr 14, 2015 at 10:02 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Well spotted!
Nicolas drew my attention to it. I am just the messenger :)
Would it be possible to have this declaredType pointing to an association? Would it be difficult to have?
That is another possibility but I prefer the solution I proposed because it is transparent for current tools using declared type.
Cheers, Alexandre
Le 14 avr. 2015 à 06:41, Usman Bhatti usman.bhatti@gmail.com a écrit :
Hi,
Consider a piece of code:
Class MyClass { public String method A() { String a; } }
In the code above, there is a relationship between the method A and the
return type String. As per my understanding, this relationship is represented with declaredType in FAMIXBehaviouralEntity.
Currently, this relationship is represented as a simple link (see
FAMIXType>>declaredType) between the two entities but not as a FAMIXAssociation. Hence, when iterating over all the links/associations between two entities, we have to specifically take into account this special case. Currently, MooseChef helps in computing this information but one should know that there are other links on top of associations:
TDependencyQueries>>queryIncomingDependencies
"Associations + typeDeclaractions" ^ self queryAllIncomingAssociations addAll: self queryIncomingTypeDeclarations; yourself
Another and more uniform solution would be to modify declaredType by
creating an additional reference. For example, a trivial solution can be:
declaredType: aType declaredType := FMMultivalueLink on: self update: #behavioursWithDeclaredType from: self declaredType to: aType. self mooseModel ifNotNil: [self mooseModel add: (FAMIXReference
new source: self; target: self declaredType) ]
This change will be transparent for the current tools.
Please provide your feedback.
Usman _______________________________________________ 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
Hi,
A Reference refers to an explicit reference to a class in the running code. So, we can definitely not use it for modeling declared type.
The problem with adding an explicit DeclaredType relationship is that it grows the model significantly with only limited benefits. For example, I do not see a real responsibility a DeclaredType entity would bare.
The only reason I see would be to be able to add it to queryAllIncomingAssociations. However, I would expect that this is mostly used internally. And even in this case, perhaps we can consider creating a DeclaredType on the fly.
Cheers, Doru
On Wed, Apr 15, 2015 at 9:48 AM, Usman Bhatti usman.bhatti@gmail.com wrote:
On Tue, Apr 14, 2015 at 10:02 PM, Alexandre Bergel < alexandre.bergel@me.com> wrote:
Well spotted!
Nicolas drew my attention to it. I am just the messenger :)
Would it be possible to have this declaredType pointing to an association? Would it be difficult to have?
That is another possibility but I prefer the solution I proposed because it is transparent for current tools using declared type.
Cheers, Alexandre
Le 14 avr. 2015 à 06:41, Usman Bhatti usman.bhatti@gmail.com a écrit
:
Hi,
Consider a piece of code:
Class MyClass { public String method A() { String a; } }
In the code above, there is a relationship between the method A and the
return type String. As per my understanding, this relationship is represented with declaredType in FAMIXBehaviouralEntity.
Currently, this relationship is represented as a simple link (see
FAMIXType>>declaredType) between the two entities but not as a FAMIXAssociation. Hence, when iterating over all the links/associations between two entities, we have to specifically take into account this special case. Currently, MooseChef helps in computing this information but one should know that there are other links on top of associations:
TDependencyQueries>>queryIncomingDependencies
"Associations + typeDeclaractions" ^ self queryAllIncomingAssociations addAll: self queryIncomingTypeDeclarations; yourself
Another and more uniform solution would be to modify declaredType by
creating an additional reference. For example, a trivial solution can be:
declaredType: aType declaredType := FMMultivalueLink on: self update:
#behavioursWithDeclaredType
from: self declaredType to: aType. self mooseModel ifNotNil: [self mooseModel add: (FAMIXReference
new source: self; target: self declaredType) ]
This change will be transparent for the current tools.
Please provide your feedback.
Usman _______________________________________________ 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
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
having all dependencies from one entity to another one is important in many situations. I would even say that it is one of the main functions of Moose to be able to represent, query and manipulate such dependencies DeclaredType of a method is a dependency from the method's class towards the declaredType
This is the reason why I implemented the allDependencies in MooseChef, to make sure there was a way to recover these dependencies as well.
Now, it is true that it would enlarge the model significantly.
Another solution that we discussed with Usman, would be to add on the fly (as you propose) new References when we ask to a type all its incomingReferences
nicolas
On 16/04/2015 23:40, Tudor Girba wrote:
Hi,
A Reference refers to an explicit reference to a class in the running code. So, we can definitely not use it for modeling declared type.
The problem with adding an explicit DeclaredType relationship is that it grows the model significantly with only limited benefits. For example, I do not see a real responsibility a DeclaredType entity would bare.
The only reason I see would be to be able to add it to queryAllIncomingAssociations. However, I would expect that this is mostly used internally. And even in this case, perhaps we can consider creating a DeclaredType on the fly.
Cheers, Doru
On Wed, Apr 15, 2015 at 9:48 AM, Usman Bhatti <usman.bhatti@gmail.com mailto:usman.bhatti@gmail.com> wrote:
On Tue, Apr 14, 2015 at 10:02 PM, Alexandre Bergel <alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>> wrote: Well spotted! Nicolas drew my attention to it. I am just the messenger :) Would it be possible to have this declaredType pointing to an association? Would it be difficult to have? That is another possibility but I prefer the solution I proposed because it is transparent for current tools using declared type. Cheers, Alexandre > Le 14 avr. 2015 à 06:41, Usman Bhatti <usman.bhatti@gmail.com <mailto:usman.bhatti@gmail.com>> a écrit : > > Hi, > > Consider a piece of code: > > Class MyClass > { > public String method A() > { > String a; > } > } > > In the code above, there is a relationship between the method A and the return type String. As per my understanding, this relationship is represented with declaredType in FAMIXBehaviouralEntity. > > Currently, this relationship is represented as a simple link (see FAMIXType>>declaredType) between the two entities but not as a FAMIXAssociation. Hence, when iterating over all the links/associations between two entities, we have to specifically take into account this special case. Currently, MooseChef helps in computing this information but one should know that there are other links on top of associations: > > TDependencyQueries>>queryIncomingDependencies > > "Associations + typeDeclaractions" > ^ self queryAllIncomingAssociations > addAll: self queryIncomingTypeDeclarations; > yourself > > Another and more uniform solution would be to modify declaredType by creating an additional reference. For example, a trivial solution can be: > > declaredType: aType > declaredType := FMMultivalueLink on: self > update: #behavioursWithDeclaredType > from: self declaredType > to: aType. > self mooseModel ifNotNil: [self mooseModel add: (FAMIXReference new source: self; target: self declaredType) ] > > This change will be transparent for the current tools. > > Please provide your feedback. > > Usman > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com http://www.tudorgirba.com
"Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
I think we should give the creation on the fly a try.
But, please create a separate DeclaredType that is not a Reference but a plain Association. As explained before, Reference has a concrete meaning that does not match DeclaredType, and it should not affect incomingReferences.
Instead it should only affect incomingAssociations.
Cheers, Doru
On Fri, Apr 17, 2015 at 9:20 AM, Nicolas Anquetil <nicolas.anquetil@inria.fr
wrote:
having all dependencies from one entity to another one is important in many situations. I would even say that it is one of the main functions of Moose to be able to represent, query and manipulate such dependencies DeclaredType of a method is a dependency from the method's class towards the declaredType
This is the reason why I implemented the allDependencies in MooseChef, to make sure there was a way to recover these dependencies as well.
Now, it is true that it would enlarge the model significantly.
Another solution that we discussed with Usman, would be to add on the fly (as you propose) new References when we ask to a type all its incomingReferences
nicolas
On 16/04/2015 23:40, Tudor Girba wrote:
Hi,
A Reference refers to an explicit reference to a class in the running code. So, we can definitely not use it for modeling declared type.
The problem with adding an explicit DeclaredType relationship is that it grows the model significantly with only limited benefits. For example, I do not see a real responsibility a DeclaredType entity would bare.
The only reason I see would be to be able to add it to queryAllIncomingAssociations. However, I would expect that this is mostly used internally. And even in this case, perhaps we can consider creating a DeclaredType on the fly.
Cheers, Doru
On Wed, Apr 15, 2015 at 9:48 AM, Usman Bhatti usman.bhatti@gmail.com wrote:
On Tue, Apr 14, 2015 at 10:02 PM, Alexandre Bergel < alexandre.bergel@me.com> wrote:
Well spotted!
Nicolas drew my attention to it. I am just the messenger :)
Would it be possible to have this declaredType pointing to an association? Would it be difficult to have?
That is another possibility but I prefer the solution I proposed because it is transparent for current tools using declared type.
Cheers, Alexandre
Le 14 avr. 2015 à 06:41, Usman Bhatti usman.bhatti@gmail.com a
écrit :
Hi,
Consider a piece of code:
Class MyClass { public String method A() { String a; } }
In the code above, there is a relationship between the method A and
the return type String. As per my understanding, this relationship is represented with declaredType in FAMIXBehaviouralEntity.
Currently, this relationship is represented as a simple link (see
FAMIXType>>declaredType) between the two entities but not as a FAMIXAssociation. Hence, when iterating over all the links/associations between two entities, we have to specifically take into account this special case. Currently, MooseChef helps in computing this information but one should know that there are other links on top of associations:
TDependencyQueries>>queryIncomingDependencies
"Associations + typeDeclaractions" ^ self queryAllIncomingAssociations addAll: self queryIncomingTypeDeclarations; yourself
Another and more uniform solution would be to modify declaredType by
creating an additional reference. For example, a trivial solution can be:
declaredType: aType declaredType := FMMultivalueLink on: self update:
#behavioursWithDeclaredType
from: self declaredType to: aType. self mooseModel ifNotNil: [self mooseModel add: (FAMIXReference
new source: self; target: self declaredType) ]
This change will be transparent for the current tools.
Please provide your feedback.
Usman _______________________________________________ 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
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
Moose-dev mailing listMoose-dev@iam.unibe.chhttps://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