MSE: Dealing with Associations

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

MSE: Dealing with Associations

Usman Bhatti
I am looking to understand what mse entities are created for associations (except inheritance i.e. invocations, access, refs) in code and how to exactly treat the duplicates. I have seen a reference of it in a bug reported for VerveineJ but I am not sure if this issue has been discussed elsewhere.

For example, 

A a;
M()
{
   a = new A();
   a = new A();
   a.CallAMethod();
   a.CallAMethod();

}

The above code creates these associations (with Verveinesharp) .. 
1. An invocations to A's constructor (duplicate constructor invocation is ignored).
2. A field access to the field a (only one instance is recorded, the others are just ignored).
3. An invocation to CallAMethod (field access is already recorded so this one is not considered).
4. A reference from method M() to type A (Duplicate reference is ignored).

Please let me know if there an anomaly.

thanx,

Usman

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: MSE: Dealing with Associations

Nicolas Anquetil
+ a reference from method M() to class A

nicolas


De: "Usman Bhatti" <[hidden email]>
À: "Moose-related development" <[hidden email]>
Envoyé: Mercredi 8 Juin 2011 11:52:21
Objet: [Moose-dev] MSE: Dealing with Associations

I am looking to understand what mse entities are created for associations (except inheritance i.e. invocations, access, refs) in code and how to exactly treat the duplicates. I have seen a reference of it in a bug reported for VerveineJ but I am not sure if this issue has been discussed elsewhere.

For example, 

A a;
M()
{
   a = new A();
   a = new A();
   a.CallAMethod();
   a.CallAMethod();

}

The above code creates these associations (with Verveinesharp) .. 
1. An invocations to A's constructor (duplicate constructor invocation is ignored).
2. A field access to the field a (only one instance is recorded, the others are just ignored).
3. An invocation to CallAMethod (field access is already recorded so this one is not considered).
4. A reference from method M() to type A (Duplicate reference is ignored).

Please let me know if there an anomaly.

thanx,

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
Reply | Threaded
Open this post in threaded view
|

Re: MSE: Dealing with Associations

Usman Bhatti
On Wed, Jun 8, 2011 at 12:07 PM, Nicolas Anquetil <[hidden email]> wrote:
+ a reference from method M() to class A

So, should I create two references? Because I am already creating a reference to type A.
 

nicolas


De: "Usman Bhatti" <[hidden email]>
À: "Moose-related development" <[hidden email]>
Envoyé: Mercredi 8 Juin 2011 11:52:21
Objet: [Moose-dev] MSE: Dealing with Associations


I am looking to understand what mse entities are created for associations (except inheritance i.e. invocations, access, refs) in code and how to exactly treat the duplicates. I have seen a reference of it in a bug reported for VerveineJ but I am not sure if this issue has been discussed elsewhere.

For example, 

A a;
M()
{
   a = new A();
   a = new A();
   a.CallAMethod();
   a.CallAMethod();

}

The above code creates these associations (with Verveinesharp) .. 
1. An invocations to A's constructor (duplicate constructor invocation is ignored).
2. A field access to the field a (only one instance is recorded, the others are just ignored).
3. An invocation to CallAMethod (field access is already recorded so this one is not considered).
4. A reference from method M() to type A (Duplicate reference is ignored).

Please let me know if there an anomaly.

thanx,

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



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: MSE: Dealing with Associations

simondenier
In reply to this post by Usman Bhatti

On 8 juin 2011, at 11:52, Usman Bhatti wrote:

I am looking to understand what mse entities are created for associations (except inheritance i.e. invocations, access, refs) in code and how to exactly treat the duplicates. I have seen a reference of it in a bug reported for VerveineJ but I am not sure if this issue has been discussed elsewhere.

For example, 

A a;
M()
{
   a = new A();
   a = new A();
   a.CallAMethod();
   a.CallAMethod();

}

The above code creates these associations (with Verveinesharp) .. 
1. An invocations to A's constructor (duplicate constructor invocation is ignored).
2. A field access to the field a (only one instance is recorded, the others are just ignored).
3. An invocation to CallAMethod (field access is already recorded so this one is not considered).
4. A reference from method M() to type A (Duplicate reference is ignored).


To me it seems like there are:
- 2 invocations to A constructor
- 2 field accesses to a
- 2 invocations to CallAMethod

There is no direct reference to class A, only indirect references through the constructor/method calls.



Please let me know if there an anomaly.

thanx,

Usman
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
Simon Denier




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: MSE: Dealing with Associations

Tudor Girba-2
Hi,

On 8 Jun 2011, at 14:21, Simon Denier wrote:

>
> On 8 juin 2011, at 11:52, Usman Bhatti wrote:
>
>> I am looking to understand what mse entities are created for associations (except inheritance i.e. invocations, access, refs) in code and how to exactly treat the duplicates. I have seen a reference of it in a bug reported for VerveineJ but I am not sure if this issue has been discussed elsewhere.
>>
>> For example,
>>
>> A a;
>> M()
>> {
>>    a = new A();
>>    a = new A();
>>    a.CallAMethod();
>>    a.CallAMethod();
>>
>> }
>>
>> The above code creates these associations (with Verveinesharp) ..
>> 1. An invocations to A's constructor (duplicate constructor invocation is ignored).
>> 2. A field access to the field a (only one instance is recorded, the others are just ignored).
>> 3. An invocation to CallAMethod (field access is already recorded so this one is not considered).
>> 4. A reference from method M() to type A (Duplicate reference is ignored).
>
>
> To me it seems like there are:
> - 2 invocations to A constructor
> - 2 field accesses to a
> - 2 invocations to CallAMethod
>
> There is no direct reference to class A, only indirect references through the constructor/method calls.

Yes! This is the correct interpretation.

Usman, please do it like suggested by Simon.

Cheers,
Doru


>
>>
>> Please let me know if there an anomaly.
>>
>> thanx,
>>
>> Usman
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> Simon Denier
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"Every thing has its own flow."





_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: MSE: Dealing with Associations

Usman Bhatti
On Wed, Jun 8, 2011 at 3:10 PM, Tudor Girba <[hidden email]> wrote:
Hi,

On 8 Jun 2011, at 14:21, Simon Denier wrote:

>
> On 8 juin 2011, at 11:52, Usman Bhatti wrote:
>
>> I am looking to understand what mse entities are created for associations (except inheritance i.e. invocations, access, refs) in code and how to exactly treat the duplicates. I have seen a reference of it in a bug reported for VerveineJ but I am not sure if this issue has been discussed elsewhere.
>>
>> For example,
>>
>> A a;
>> M()
>> {
>>    a = new A();
>>    a = new A();
>>    a.CallAMethod();
>>    a.CallAMethod();
>>
>> }
>>
>> The above code creates these associations (with Verveinesharp) ..
>> 1. An invocations to A's constructor (duplicate constructor invocation is ignored).
>> 2. A field access to the field a (only one instance is recorded, the others are just ignored).
>> 3. An invocation to CallAMethod (field access is already recorded so this one is not considered).
>> 4. A reference from method M() to type A (Duplicate reference is ignored).
>
>
> To me it seems like there are:
> - 2 invocations to A constructor
> - 2 field accesses to a
> - 2 invocations to CallAMethod
>
> There is no direct reference to class A, only indirect references through the constructor/method calls. 

Yes! This is the correct interpretation. 

Usman, please do it like suggested by Simon.

So, we keep the duplicates in MSE. Ok I'll change VerveineSharp to implement this interpretation. But I do not understand what is mean by direct and indirect references because as I understand the meta-model provides only one type i.e. a Reference class to instantiate references. How do we do the different between direct and indirect?


Cheers,
Doru


>
>>
>> Please let me know if there an anomaly.
>>
>> thanx,
>>
>> Usman
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> Simon Denier
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"Every thing has its own flow."





_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: MSE: Dealing with Associations

Tudor Girba-2
Hi,

On 8 Jun 2011, at 15:45, Usman Bhatti wrote:

> On Wed, Jun 8, 2011 at 3:10 PM, Tudor Girba <[hidden email]> wrote:
> Hi,
>
> On 8 Jun 2011, at 14:21, Simon Denier wrote:
>
> >
> > On 8 juin 2011, at 11:52, Usman Bhatti wrote:
> >
> >> I am looking to understand what mse entities are created for associations (except inheritance i.e. invocations, access, refs) in code and how to exactly treat the duplicates. I have seen a reference of it in a bug reported for VerveineJ but I am not sure if this issue has been discussed elsewhere.
> >>
> >> For example,
> >>
> >> A a;
> >> M()
> >> {
> >>    a = new A();
> >>    a = new A();
> >>    a.CallAMethod();
> >>    a.CallAMethod();
> >>
> >> }
> >>
> >> The above code creates these associations (with Verveinesharp) ..
> >> 1. An invocations to A's constructor (duplicate constructor invocation is ignored).
> >> 2. A field access to the field a (only one instance is recorded, the others are just ignored).
> >> 3. An invocation to CallAMethod (field access is already recorded so this one is not considered).
> >> 4. A reference from method M() to type A (Duplicate reference is ignored).
> >
> >
> > To me it seems like there are:
> > - 2 invocations to A constructor
> > - 2 field accesses to a
> > - 2 invocations to CallAMethod
> >
> > There is no direct reference to class A, only indirect references through the constructor/method calls.
>
> Yes! This is the correct interpretation.
>
> Usman, please do it like suggested by Simon.
>
> So, we keep the duplicates in MSE. Ok I'll change VerveineSharp to implement this interpretation. But I do not understand what is mean by direct and indirect references because as I understand the meta-model provides only one type i.e. a Reference class to instantiate references. How do we do the different between direct and indirect?

What Simon meant is that in the code there is no Reference to class A. There are only calls to the constructor A. And a call to a constructor can be considered an indirect reference. But, the model should only represent what is found in the code.

Cheers,
Doru


>
> Cheers,
> Doru
>
>
> >
> >>
> >> Please let me know if there an anomaly.
> >>
> >> thanx,
> >>
> >> Usman
> >> _______________________________________________
> >> Moose-dev mailing list
> >> [hidden email]
> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >
> > --
> > Simon Denier
> >
> >
> >
> > _______________________________________________
> > Moose-dev mailing list
> > [hidden email]
> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow."
>
>
>
>
>
> _______________________________________________
> 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

--
www.tudorgirba.com

"Don't give to get. Just give."






_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: MSE: Dealing with Associations

Usman Bhatti
On Wed, Jun 8, 2011 at 3:54 PM, Tudor Girba <[hidden email]> wrote:
Hi,

On 8 Jun 2011, at 15:45, Usman Bhatti wrote:

> On Wed, Jun 8, 2011 at 3:10 PM, Tudor Girba <[hidden email]> wrote:
> Hi,
>
> On 8 Jun 2011, at 14:21, Simon Denier wrote:
>
> >
> > On 8 juin 2011, at 11:52, Usman Bhatti wrote:
> >
> >> I am looking to understand what mse entities are created for associations (except inheritance i.e. invocations, access, refs) in code and how to exactly treat the duplicates. I have seen a reference of it in a bug reported for VerveineJ but I am not sure if this issue has been discussed elsewhere.
> >>
> >> For example,
> >>
> >> A a;
> >> M()
> >> {
> >>    a = new A();
> >>    a = new A();
> >>    a.CallAMethod();
> >>    a.CallAMethod();
> >>
> >> }
> >>
> >> The above code creates these associations (with Verveinesharp) ..
> >> 1. An invocations to A's constructor (duplicate constructor invocation is ignored).
> >> 2. A field access to the field a (only one instance is recorded, the others are just ignored).
> >> 3. An invocation to CallAMethod (field access is already recorded so this one is not considered).
> >> 4. A reference from method M() to type A (Duplicate reference is ignored).
> >
> >
> > To me it seems like there are:
> > - 2 invocations to A constructor
> > - 2 field accesses to a
> > - 2 invocations to CallAMethod
> >
> > There is no direct reference to class A, only indirect references through the constructor/method calls.
>
> Yes! This is the correct interpretation.
>
> Usman, please do it like suggested by Simon.
>
> So, we keep the duplicates in MSE. Ok I'll change VerveineSharp to implement this interpretation. But I do not understand what is mean by direct and indirect references because as I understand the meta-model provides only one type i.e. a Reference class to instantiate references. How do we do the different between direct and indirect?

What Simon meant is that in the code there is no Reference to class A. There are only calls to the constructor A. And a call to a constructor can be considered an indirect reference. But, the model should only represent what is found in the code.

Is direct reference = static reference?
Because we can only refer to an object of a class through a field or through a constructor. Static references refer to the class directly.Sorry for insisting on that but I want to implement this thing correctly.
 

Cheers,
Doru


>
> Cheers,
> Doru
>
>
> >
> >>
> >> Please let me know if there an anomaly.
> >>
> >> thanx,
> >>
> >> Usman
> >> _______________________________________________
> >> Moose-dev mailing list
> >> [hidden email]
> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >
> > --
> > Simon Denier
> >
> >
> >
> > _______________________________________________
> > Moose-dev mailing list
> > [hidden email]
> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow."
>
>
>
>
>
> _______________________________________________
> 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

--
www.tudorgirba.com

"Don't give to get. Just give."






_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: MSE: Dealing with Associations

Tudor Girba-2
Hi,

On 8 Jun 2011, at 17:07, Usman Bhatti wrote:

> On Wed, Jun 8, 2011 at 3:54 PM, Tudor Girba <[hidden email]> wrote:
> Hi,
>
> On 8 Jun 2011, at 15:45, Usman Bhatti wrote:
>
> > On Wed, Jun 8, 2011 at 3:10 PM, Tudor Girba <[hidden email]> wrote:
> > Hi,
> >
> > On 8 Jun 2011, at 14:21, Simon Denier wrote:
> >
> > >
> > > On 8 juin 2011, at 11:52, Usman Bhatti wrote:
> > >
> > >> I am looking to understand what mse entities are created for associations (except inheritance i.e. invocations, access, refs) in code and how to exactly treat the duplicates. I have seen a reference of it in a bug reported for VerveineJ but I am not sure if this issue has been discussed elsewhere.
> > >>
> > >> For example,
> > >>
> > >> A a;
> > >> M()
> > >> {
> > >>    a = new A();
> > >>    a = new A();
> > >>    a.CallAMethod();
> > >>    a.CallAMethod();
> > >>
> > >> }
> > >>
> > >> The above code creates these associations (with Verveinesharp) ..
> > >> 1. An invocations to A's constructor (duplicate constructor invocation is ignored).
> > >> 2. A field access to the field a (only one instance is recorded, the others are just ignored).
> > >> 3. An invocation to CallAMethod (field access is already recorded so this one is not considered).
> > >> 4. A reference from method M() to type A (Duplicate reference is ignored).
> > >
> > >
> > > To me it seems like there are:
> > > - 2 invocations to A constructor
> > > - 2 field accesses to a
> > > - 2 invocations to CallAMethod
> > >
> > > There is no direct reference to class A, only indirect references through the constructor/method calls.
> >
> > Yes! This is the correct interpretation.
> >
> > Usman, please do it like suggested by Simon.
> >
> > So, we keep the duplicates in MSE. Ok I'll change VerveineSharp to implement this interpretation. But I do not understand what is mean by direct and indirect references because as I understand the meta-model provides only one type i.e. a Reference class to instantiate references. How do we do the different between direct and indirect?
>
> What Simon meant is that in the code there is no Reference to class A. There are only calls to the constructor A. And a call to a constructor can be considered an indirect reference. But, the model should only represent what is found in the code.
>
> Is direct reference = static reference?

Pretty much.

> Because we can only refer to an object of a class through a field or through a constructor. Static references refer to the class directly.Sorry for insisting on that but I want to implement this thing correctly.

Well, this is an unclear territory, so do not feel bad for insisting :). The thing is like this. If you would manipulate the class as a variable, this would be a reference to that class. For example:
- if you pass the class as a parameter to a function, or
- if you invoke a static method on a class

Is that better?

Cheers,
Doru

>  
>
> Cheers,
> Doru
>
>
> >
> > Cheers,
> > Doru
> >
> >
> > >
> > >>
> > >> Please let me know if there an anomaly.
> > >>
> > >> thanx,
> > >>
> > >> Usman
> > >> _______________________________________________
> > >> Moose-dev mailing list
> > >> [hidden email]
> > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> > >
> > > --
> > > Simon Denier
> > >
> > >
> > >
> > > _______________________________________________
> > > Moose-dev mailing list
> > > [hidden email]
> > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >
> > --
> > www.tudorgirba.com
> >
> > "Every thing has its own flow."
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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
>
> --
> www.tudorgirba.com
>
> "Don't give to get. Just give."
>
>
>
>
>
>
> _______________________________________________
> 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

--
www.tudorgirba.com

"Live like you mean it."


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: MSE: Dealing with Associations

Usman Bhatti
On Wed, Jun 8, 2011 at 5:16 PM, Tudor Girba <[hidden email]> wrote:
Hi,

On 8 Jun 2011, at 17:07, Usman Bhatti wrote:

> On Wed, Jun 8, 2011 at 3:54 PM, Tudor Girba <[hidden email]> wrote:
> Hi,
>
> On 8 Jun 2011, at 15:45, Usman Bhatti wrote:
>
> > On Wed, Jun 8, 2011 at 3:10 PM, Tudor Girba <[hidden email]> wrote:
> > Hi,
> >
> > On 8 Jun 2011, at 14:21, Simon Denier wrote:
> >
> > >
> > > On 8 juin 2011, at 11:52, Usman Bhatti wrote:
> > >
> > >> I am looking to understand what mse entities are created for associations (except inheritance i.e. invocations, access, refs) in code and how to exactly treat the duplicates. I have seen a reference of it in a bug reported for VerveineJ but I am not sure if this issue has been discussed elsewhere.
> > >>
> > >> For example,
> > >>
> > >> A a;
> > >> M()
> > >> {
> > >>    a = new A();
> > >>    a = new A();
> > >>    a.CallAMethod();
> > >>    a.CallAMethod();
> > >>
> > >> }
> > >>
> > >> The above code creates these associations (with Verveinesharp) ..
> > >> 1. An invocations to A's constructor (duplicate constructor invocation is ignored).
> > >> 2. A field access to the field a (only one instance is recorded, the others are just ignored).
> > >> 3. An invocation to CallAMethod (field access is already recorded so this one is not considered).
> > >> 4. A reference from method M() to type A (Duplicate reference is ignored).
> > >
> > >
> > > To me it seems like there are:
> > > - 2 invocations to A constructor
> > > - 2 field accesses to a
> > > - 2 invocations to CallAMethod
> > >
> > > There is no direct reference to class A, only indirect references through the constructor/method calls.
> >
> > Yes! This is the correct interpretation.
> >
> > Usman, please do it like suggested by Simon.
> >
> > So, we keep the duplicates in MSE. Ok I'll change VerveineSharp to implement this interpretation. But I do not understand what is mean by direct and indirect references because as I understand the meta-model provides only one type i.e. a Reference class to instantiate references. How do we do the different between direct and indirect?
>
> What Simon meant is that in the code there is no Reference to class A. There are only calls to the constructor A. And a call to a constructor can be considered an indirect reference. But, the model should only represent what is found in the code.
>
> Is direct reference = static reference?

Pretty much.

> Because we can only refer to an object of a class through a field or through a constructor. Static references refer to the class directly.Sorry for insisting on that but I want to implement this thing correctly.

Well, this is an unclear territory, so do not feel bad for insisting :). The thing is like this. If you would manipulate the class as a variable, this would be a reference to that class. For example:
- if you pass the class as a parameter to a function, or

just a final clarification (I hope :-)
m (A a)
{
   //do square brackets provide correct interpretation?
   a.CallAmethod(); [not a reference, access and invocation only]
   A b = new A();
   a = b; [reference to A + 2 accesses to A]
}
 
- if you invoke a static method on a class

Is that better?

Yep, much better :-).. thanx
 

Cheers,
Doru

>
>
> Cheers,
> Doru
>
>
> >
> > Cheers,
> > Doru
> >
> >
> > >
> > >>
> > >> Please let me know if there an anomaly.
> > >>
> > >> thanx,
> > >>
> > >> Usman
> > >> _______________________________________________
> > >> Moose-dev mailing list
> > >> [hidden email]
> > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> > >
> > > --
> > > Simon Denier
> > >
> > >
> > >
> > > _______________________________________________
> > > Moose-dev mailing list
> > > [hidden email]
> > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >
> > --
> > www.tudorgirba.com
> >
> > "Every thing has its own flow."
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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
>
> --
> www.tudorgirba.com
>
> "Don't give to get. Just give."
>
>
>
>
>
>
> _______________________________________________
> 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

--
www.tudorgirba.com

"Live like you mean it."


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: MSE: Dealing with Associations

Tudor Girba-2
Hi,

On 8 Jun 2011, at 18:29, Usman Bhatti wrote:

> On Wed, Jun 8, 2011 at 5:16 PM, Tudor Girba <[hidden email]> wrote:
> Hi,
>
> On 8 Jun 2011, at 17:07, Usman Bhatti wrote:
>
> > On Wed, Jun 8, 2011 at 3:54 PM, Tudor Girba <[hidden email]> wrote:
> > Hi,
> >
> > On 8 Jun 2011, at 15:45, Usman Bhatti wrote:
> >
> > > On Wed, Jun 8, 2011 at 3:10 PM, Tudor Girba <[hidden email]> wrote:
> > > Hi,
> > >
> > > On 8 Jun 2011, at 14:21, Simon Denier wrote:
> > >
> > > >
> > > > On 8 juin 2011, at 11:52, Usman Bhatti wrote:
> > > >
> > > >> I am looking to understand what mse entities are created for associations (except inheritance i.e. invocations, access, refs) in code and how to exactly treat the duplicates. I have seen a reference of it in a bug reported for VerveineJ but I am not sure if this issue has been discussed elsewhere.
> > > >>
> > > >> For example,
> > > >>
> > > >> A a;
> > > >> M()
> > > >> {
> > > >>    a = new A();
> > > >>    a = new A();
> > > >>    a.CallAMethod();
> > > >>    a.CallAMethod();
> > > >>
> > > >> }
> > > >>
> > > >> The above code creates these associations (with Verveinesharp) ..
> > > >> 1. An invocations to A's constructor (duplicate constructor invocation is ignored).
> > > >> 2. A field access to the field a (only one instance is recorded, the others are just ignored).
> > > >> 3. An invocation to CallAMethod (field access is already recorded so this one is not considered).
> > > >> 4. A reference from method M() to type A (Duplicate reference is ignored).
> > > >
> > > >
> > > > To me it seems like there are:
> > > > - 2 invocations to A constructor
> > > > - 2 field accesses to a
> > > > - 2 invocations to CallAMethod
> > > >
> > > > There is no direct reference to class A, only indirect references through the constructor/method calls.
> > >
> > > Yes! This is the correct interpretation.
> > >
> > > Usman, please do it like suggested by Simon.
> > >
> > > So, we keep the duplicates in MSE. Ok I'll change VerveineSharp to implement this interpretation. But I do not understand what is mean by direct and indirect references because as I understand the meta-model provides only one type i.e. a Reference class to instantiate references. How do we do the different between direct and indirect?
> >
> > What Simon meant is that in the code there is no Reference to class A. There are only calls to the constructor A. And a call to a constructor can be considered an indirect reference. But, the model should only represent what is found in the code.
> >
> > Is direct reference = static reference?
>
> Pretty much.
>
> > Because we can only refer to an object of a class through a field or through a constructor. Static references refer to the class directly.Sorry for insisting on that but I want to implement this thing correctly.
>
> Well, this is an unclear territory, so do not feel bad for insisting :). The thing is like this. If you would manipulate the class as a variable, this would be a reference to that class. For example:
> - if you pass the class as a parameter to a function, or
>
> just a final clarification (I hope :-)
> m (A a)
> {
>    //do square brackets provide correct interpretation?
>    a.CallAmethod(); [not a reference, access and invocation only]

Correct.

>    A b = new A();

Here we have an access to b and an invocation to constructor A.

>    a = b; [reference to A + 2 accesses to A]

No. There is no reference to A, only an access to a and an access to b.

Cheers,
Doru


> }





> - if you invoke a static method on a class
>
> Is that better?
>
> Yep, much better :-).. thanx
>  
>
> Cheers,
> Doru
>
> >
> >
> > Cheers,
> > Doru
> >
> >
> > >
> > > Cheers,
> > > Doru
> > >
> > >
> > > >
> > > >>
> > > >> Please let me know if there an anomaly.
> > > >>
> > > >> thanx,
> > > >>
> > > >> Usman
> > > >> _______________________________________________
> > > >> Moose-dev mailing list
> > > >> [hidden email]
> > > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> > > >
> > > > --
> > > > Simon Denier
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Moose-dev mailing list
> > > > [hidden email]
> > > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> > >
> > > --
> > > www.tudorgirba.com
> > >
> > > "Every thing has its own flow."
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
> >
> > --
> > www.tudorgirba.com
> >
> > "Don't give to get. Just give."
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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
>
> --
> www.tudorgirba.com
>
> "Live like you mean it."
>
>
> _______________________________________________
> 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

--
www.tudorgirba.com

"Every thing has its own flow."





_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: MSE: Dealing with Associations

Usman Bhatti
On Wed, Jun 8, 2011 at 6:55 PM, Tudor Girba <[hidden email]> wrote:
Hi,

On 8 Jun 2011, at 18:29, Usman Bhatti wrote:

> On Wed, Jun 8, 2011 at 5:16 PM, Tudor Girba <[hidden email]> wrote:
> Hi,
>
> On 8 Jun 2011, at 17:07, Usman Bhatti wrote:
>
> > On Wed, Jun 8, 2011 at 3:54 PM, Tudor Girba <[hidden email]> wrote:
> > Hi,
> >
> > On 8 Jun 2011, at 15:45, Usman Bhatti wrote:
> >
> > > On Wed, Jun 8, 2011 at 3:10 PM, Tudor Girba <[hidden email]> wrote:
> > > Hi,
> > >
> > > On 8 Jun 2011, at 14:21, Simon Denier wrote:
> > >
> > > >
> > > > On 8 juin 2011, at 11:52, Usman Bhatti wrote:
> > > >
> > > >> I am looking to understand what mse entities are created for associations (except inheritance i.e. invocations, access, refs) in code and how to exactly treat the duplicates. I have seen a reference of it in a bug reported for VerveineJ but I am not sure if this issue has been discussed elsewhere.
> > > >>
> > > >> For example,
> > > >>
> > > >> A a;
> > > >> M()
> > > >> {
> > > >>    a = new A();
> > > >>    a = new A();
> > > >>    a.CallAMethod();
> > > >>    a.CallAMethod();
> > > >>
> > > >> }
> > > >>
> > > >> The above code creates these associations (with Verveinesharp) ..
> > > >> 1. An invocations to A's constructor (duplicate constructor invocation is ignored).
> > > >> 2. A field access to the field a (only one instance is recorded, the others are just ignored).
> > > >> 3. An invocation to CallAMethod (field access is already recorded so this one is not considered).
> > > >> 4. A reference from method M() to type A (Duplicate reference is ignored).
> > > >
> > > >
> > > > To me it seems like there are:
> > > > - 2 invocations to A constructor
> > > > - 2 field accesses to a
> > > > - 2 invocations to CallAMethod
> > > >
> > > > There is no direct reference to class A, only indirect references through the constructor/method calls.
> > >
> > > Yes! This is the correct interpretation.
> > >
> > > Usman, please do it like suggested by Simon.
> > >
> > > So, we keep the duplicates in MSE. Ok I'll change VerveineSharp to implement this interpretation. But I do not understand what is mean by direct and indirect references because as I understand the meta-model provides only one type i.e. a Reference class to instantiate references. How do we do the different between direct and indirect?
> >
> > What Simon meant is that in the code there is no Reference to class A. There are only calls to the constructor A. And a call to a constructor can be considered an indirect reference. But, the model should only represent what is found in the code.
> >
> > Is direct reference = static reference?
>
> Pretty much.
>
> > Because we can only refer to an object of a class through a field or through a constructor. Static references refer to the class directly.Sorry for insisting on that but I want to implement this thing correctly.
>
> Well, this is an unclear territory, so do not feel bad for insisting :). The thing is like this. If you would manipulate the class as a variable, this would be a reference to that class. For example:
> - if you pass the class as a parameter to a function, or
>
> just a final clarification (I hope :-)
> m (A a)
> {
>    //do square brackets provide correct interpretation?
>    a.CallAmethod(); [not a reference, access and invocation only]

Correct.

>    A b = new A();

Here we have an access to b and an invocation to constructor A.

>    a = b; [reference to A + 2 accesses to A]

No. There is no reference to A, only an access to a and an access to b.

Ok. Now I understand. Merely, passing a type as a parameter creates a reference. It is not important how that parameter is used in the method.

thanx a lot

Cheers,
Doru


> }





> - if you invoke a static method on a class
>
> Is that better?
>
> Yep, much better :-).. thanx
>
>
> Cheers,
> Doru
>
> >
> >
> > Cheers,
> > Doru
> >
> >
> > >
> > > Cheers,
> > > Doru
> > >
> > >
> > > >
> > > >>
> > > >> Please let me know if there an anomaly.
> > > >>
> > > >> thanx,
> > > >>
> > > >> Usman
> > > >> _______________________________________________
> > > >> Moose-dev mailing list
> > > >> [hidden email]
> > > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> > > >
> > > > --
> > > > Simon Denier
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Moose-dev mailing list
> > > > [hidden email]
> > > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> > >
> > > --
> > > www.tudorgirba.com
> > >
> > > "Every thing has its own flow."
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
> >
> > --
> > www.tudorgirba.com
> >
> > "Don't give to get. Just give."
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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
>
> --
> www.tudorgirba.com
>
> "Live like you mean it."
>
>
> _______________________________________________
> 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

--
www.tudorgirba.com

"Every thing has its own flow."





_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: MSE: Dealing with Associations

simondenier

On 8 juin 2011, at 23:12, Usman Bhatti wrote:


>    a = b; [reference to A + 2 accesses to A]

No. There is no reference to A, only an access to a and an access to b.

Ok. Now I understand. Merely, passing a type as a parameter creates a reference. It is not important how that parameter is used in the method.


Nope. A Famix reference in C# would be like:

ClassA.staticMethodCall()

-> one reference to ClassA and one invocation

So a reference has some kind of semantic meaning for the program (it is "used" during the execution, it's not just something for typechecking). If you want, ClassA is some kind of global variable which is accessed during execution (it's like that in Smalltalk actually).

Now the "reference" to a type in a parameter is modelled in a different manner: you actually have a FamixParameter entity which has a #declaredType property, which points to the referenced FamixType. Same thing with FamixAttribute. That's what I meant by "indirect" reference (although I don't like the term): you don't reify the dependency directly, but you can still access it through #declaredType.


One problem with this approach is that #declaredType property is often overlooked in dependency analysis (especially since in Smalltalk models this prop is rarely used or even set). I don't know what could be the impact of collecting #declaredType with the other dependencies.
---> This is actually a problem in MooseChef and could be largely discussed.

--
Simon Denier




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: MSE: Dealing with Associations

Tudor Girba-2
Hi,

On 9 Jun 2011, at 10:17, Simon Denier wrote:

>
> On 8 juin 2011, at 23:12, Usman Bhatti wrote:
>
>>
>> >    a = b; [reference to A + 2 accesses to A]
>>
>> No. There is no reference to A, only an access to a and an access to b.
>>
>> Ok. Now I understand. Merely, passing a type as a parameter creates a reference. It is not important how that parameter is used in the method.
>
>
> Nope. A Famix reference in C# would be like:
>
> ClassA.staticMethodCall()
>
> -> one reference to ClassA and one invocation
>
> So a reference has some kind of semantic meaning for the program (it is "used" during the execution, it's not just something for typechecking). If you want, ClassA is some kind of global variable which is accessed during execution (it's like that in Smalltalk actually).
>
> Now the "reference" to a type in a parameter is modelled in a different manner: you actually have a FamixParameter entity which has a #declaredType property, which points to the referenced FamixType. Same thing with FamixAttribute. That's what I meant by "indirect" reference (although I don't like the term): you don't reify the dependency directly, but you can still access it through #declaredType.

Indeed, simply declaring the type of a parameter is not a reference. However, passing a class as an argument to a method call is.

> One problem with this approach is that #declaredType property is often overlooked in dependency analysis (especially since in Smalltalk models this prop is rarely used or even set). I don't know what could be the impact of collecting #declaredType with the other dependencies.
> ---> This is actually a problem in MooseChef and could be largely discussed.

That is a good point.

Cheers,
Doru



> --
> Simon Denier
>
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"To lead is not to demand things, it is to make them happen."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: MSE: Dealing with Associations

Stéphane Ducasse
>
> Indeed, simply declaring the type of a parameter is not a reference. However, passing a class as an argument to a method call is.
>
>> One problem with this approach is that #declaredType property is often overlooked in dependency analysis (especially since in Smalltalk models this prop is rarely used or even set). I don't know what could be the impact of collecting #declaredType with the other dependencies.
>> ---> This is actually a problem in MooseChef and could be largely discussed.
>
> That is a good point.

I have the impression that it would be good to have the option to declare declaredType as reference. Because it would make analyses based on reference sronger and more useful.
I think that we historically did not do it because we do not have that in Smalltalk.

Stef


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev