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(a)gmail.com
<mailto:usman.bhatti@gmail.com>> wrote:
On Tue, Apr 14, 2015 at 10:02 PM, Alexandre Bergel
<alexandre.bergel(a)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(a)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(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch <mailto:Moose-dev@iam.unibe.ch>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev