revisiting declaredType
Locked
 
|
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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 <[hidden email]> 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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
On Tue, Apr 14, 2015 at 10:02 PM, Alexandre Bergel <[hidden email]> wrote: Well spotted! Nicolas drew my attention to it. I am just the messenger :)
That is another possibility but I prefer the solution I proposed because it is transparent for current tools using declared type.
_______________________________________________ Moose-dev mailing list [hidden email] 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 <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] 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:
_______________________________________________ Moose-dev mailing list [hidden email] 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 <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |