29 Jul
2015
29 Jul
'15
4:14 p.m.
Hi,
We have improved MooseChef with a generic version MooseQuery.
In the following when we talk about MooseChef, it means the current version available by
default in Moose. When we talk about MooseQuery, it means the generic improved version,
available on Anne’s smalltalkHub repository.
All the tests of MooseChef except 4 are passing when using our new MooseQuery API.
These four tests concern the same point package scope for extension method.
Considering classA having a method methodA1 calling a method methodBExt1 that extends
classB.
classB is defined in pckgB and its extension method by pckgC.
Considering the two following requests:
1. classA queryOutgoingInvocation atClassScope atPackageScope
2. classA queryOutgoingInvocation atPackageScope
To the first query, MooseChef and MooseQuery answer the same: pckgB
To the second query, MooseChef answers pckgC and MooseQuery answers pckgB and pckgC.
So first question: What is the expected behavior? What do we want?
According to us, MooseQuery behavior is more consistent.
***************
Considering now Java code.
class1 contains a method method1 which in its turn contains an inner class innerClass2.
innerClass2 contains 2 methods method21 and method22.
the following query:
innerClass2 methodScope
In MooseChef this query has for result method21 and method22.
The following query:
innerClass2 atScope: FAMIXMethod
In MooseQuery this query has for result method1. Indeed, the atScope: method look for the
container (also called parent).
So the second question: what is the expected behavior? Do we want like in MooseQuery that
atScope: by default always goes up in the containment tree since it is a generic version
of atTypeScope, atPackageScope... and do we want another method to goes down in the
containment tree?
In MooseChef, methodScope, always goes down to look for the contained methods. typeScope
always goes up except for ScopingEntities. These methods have been implemented for each
type of entities. It is what we want to avoid with MooseQuery.
******************
It is clear that Synectique will soon migrate to this new version and that our project of
SQL analysis will also use it. Please don’t hesitate to use it.
MCHttpRepository
location: 'http://smalltalkhub.com/mc/AnneEtien/MooseQueryDraft/main'
user: ''
password: ‘'
We will do as soon as possible a small doc to explain the usage.
Thank you in advance for your answer to our questions.
Jean-Christophe and Anne
30 Jul
30 Jul
1:34 p.m.
New subject: News about the new version of MooseChef and questions
Hi,
Very nice work. See more answers inline.
On Wed, Jul 29, 2015 at 4:14 PM, Anne Etien <anne.etien(a)univ-lille1.fr>
wrote:
Hi,
We have improved MooseChef with a generic version MooseQuery.
In the following when we talk about MooseChef, it means the current
version available by default in Moose. When we talk about MooseQuery, it
means the generic improved version, available on Anne’s smalltalkHub
repository.
All the tests of MooseChef except 4 are passing when using our new
MooseQuery API.
These four tests concern the same point package scope for extension method.
Considering classA having a method methodA1 calling a method methodBExt1
that extends classB.
classB is defined in pckgB and its extension method by pckgC.
Considering the two following requests:
1. classA queryOutgoingInvocation atClassScope atPackageScope
2. classA queryOutgoingInvocation atPackageScope
To the first query, MooseChef and MooseQuery answer the same: pckgB
To the second query, MooseChef answers pckgC and MooseQuery answers pckgB
and pckgC.
So first question: What is the expected behavior? What do we want?
According to us, MooseQuery behavior is more consistent.
In this example, the MooseChef is the more consistent one. Here is why.
at*Scope is applied to target entities (like opposites), not to
associations. In the second case, the associations point only to
methodBExt1. Thus, the expected at*Scope is applied on only methodBExt1
(and not to its class). This should be preserved.
Imagine that you would like to reason about dependencies between pckgA,
pckgB, and pckgC, and imagine that the contract we are looking for is to
only allow pckgA to depend on pckgC. Having a way to query that the
dependencies do not actually go to pckgB is quite important.
I understand how this can be difficult to implement in the current
implementation, given that for atPackageScope you depend on traversing the
defined parentSelectors, but this is an important issue and we should find
a way to deal with it.
How about if there is a parentSelector that satisfies the condition for the
current entity, we do not traverse further? So, if you start from a
FAMIXMethod, you will stop because there is a parentPackage. What do you
think?
***************
Considering now Java code.
class1 contains a method method1 which in its turn contains an inner class
innerClass2. innerClass2 contains 2 methods method21 and method22.
the following query:
innerClass2 methodScope
In MooseChef this query has for result method21 and method22.
The following query:
innerClass2 atScope: FAMIXMethod
In MooseQuery this query has for result method1. Indeed, the atScope:
method look for the container (also called parent).
So the second question: what is the expected behavior? Do we want like in
MooseQuery that atScope: by default always goes up in the containment tree
since it is a generic version of atTypeScope, atPackageScope... and do we
want another method to goes down in the containment tree?
In MooseChef, methodScope, always goes down to look for the contained
methods. typeScope always goes up except for ScopingEntities. These methods
have been implemented for each type of entities. It is what we want to
avoid with MooseQuery.
Indeed, this semantics of at*Scope is confusing. It was tempting to do it
at the time, but since then I basically never used it, so we should
discard. And indeed, adding another operator like to*Scope would be both
simpler to understand and safer to use.
******************
It is clear that Synectique will soon migrate to this new version and that
our project of SQL analysis will also use it. Please don’t hesitate to use
it.
MCHttpRepository
location: '
http://smalltalkhub.com/mc/AnneEtien/MooseQueryDraft/main'
user: ''
password: ‘'
We will do as soon as possible a small doc to explain the usage.
Thank you in advance for your answer to our questions.
So, I looked at the code a bit. We should integrate this as soon as
possible.
However, first we need to address a couple of issues:
- the traversing of parents like described above
- there should be no need for the <parentMetaClass:> annotation. This is
derived from the parentSelector
- the parentSelector annotation should be moved to the method that defines
the property. Also, we should prefix it with MSE and I would call it
ParentScope. So, something like this: FAMIXType>>container
<MSEProperty: #container type: #FAMIXContainerEntity opposite: #types>
<MSEComment: 'Container entity to which this type belongs to. Container is
a namespace, not a package (Smalltalk).'>
*<MSEParentScope>*
^container
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
2:30 p.m.
Hi,
Very nice work. See more answers inline.
Thanks!
On Wed, Jul 29, 2015 at 4:14 PM, Anne Etien
<anne.etien(a)univ-lille1.fr>
wrote:
We are not sure to understand. With MooseChef, if you work at class
level, you need to load pckgB because of classB. If you work at package
level, you do not see the dependency to pckgB and load only pckgC.
However pckgC cannot be loaded without pckgB (methodBExt1 cannot exist
if pckgB is not loaded). So, it is true that methodBExt1 directly
depends on only pckgC but it also depends indirectly on pckgB, which is
quite important to know. Without pckgB, classB does not exist and also
methodBExt1. MooseQuery has the advantage to be consistent when working
at class level or package level.
Hi,
We have improved MooseChef with a generic version MooseQuery.
In the following when we talk about MooseChef, it means the current
version available by default in Moose. When we talk about MooseQuery, it
means the generic improved version, available on Anne’s smalltalkHub
repository.
All the tests of MooseChef except 4 are passing when using our new
MooseQuery API.
These four tests concern the same point package scope for extension method.
Considering classA having a method methodA1 calling a method methodBExt1
that extends classB.
classB is defined in pckgB and its extension method by pckgC.
Considering the two following requests:
1. classA queryOutgoingInvocation atClassScope atPackageScope
2. classA queryOutgoingInvocation atPackageScope
To the first query, MooseChef and MooseQuery answer the same: pckgB
To the second query, MooseChef answers pckgC and MooseQuery answers pckgB
and pckgC.
So first question: What is the expected behavior? What do we want?
According to us, MooseQuery behavior is more consistent.
In this example, the MooseChef is the more consistent one. Here is why.
at*Scope is applied to target entities (like opposites), not to
associations. In the second case, the associations point only to
methodBExt1. Thus, the expected at*Scope is applied on only methodBExt1
(and not to its class). This should be preserved.
Imagine that you would like to reason about dependencies between pckgA,
pckgB, and pckgC, and imagine that the contract we are looking for is to
only allow pckgA to depend on pckgC. Having a way to query that the
dependencies do not actually go to pckgB is quite important. I understand how this can be difficult to implement in
the current
implementation, given that for atPackageScope you depend on traversing the
defined parentSelectors, but this is an important issue and we should find
a way to deal with it.
How about if there is a parentSelector that satisfies the condition for the
current entity, we do not traverse further? So, if you start from a
FAMIXMethod, you will stop because there is a parentPackage. What do you
think?
We will try to do it.
***************
Considering now Java code.
class1 contains a method method1 which in its turn contains an inner class
innerClass2. innerClass2 contains 2 methods method21 and method22.
the following query:
innerClass2 methodScope
In MooseChef this query has for result method21 and method22.
The following query:
innerClass2 atScope: FAMIXMethod
In MooseQuery this query has for result method1. Indeed, the atScope:
method look for the container (also called parent).
So the second question: what is the expected behavior? Do we want like in
MooseQuery that atScope: by default always goes up in the containment tree
since it is a generic version of atTypeScope, atPackageScope... and do we
want another method to goes down in the containment tree?
In MooseChef, methodScope, always goes down to look for the contained
methods. typeScope always goes up except for ScopingEntities. These methods
have been implemented for each type of entities. It is what we want to
avoid with MooseQuery.
Indeed, this semantics of at*Scope is confusing. It was tempting to do it
at the time, but since then I basically never used it, so we should
discard. And indeed, adding another operator like to*Scope would be both
simpler to understand and safer to use. ******************
As explained above, we disagree.
It is clear that Synectique will soon migrate to this new version and that
our project of SQL analysis will also use it. Please don’t hesitate to use
it.
MCHttpRepository
location: '
http://smalltalkhub.com/mc/AnneEtien/MooseQueryDraft/main'
user: ''
password: ‘'
We will do as soon as possible a small doc to explain the usage.
Thank you in advance for your answer to our questions.
So, I looked at the code a bit. We should integrate this as soon as
possible.
However, first we need to address a couple of issues:
- the traversing of parents like described above - there should be no need for the
<parentMetaClass:> annotation. This is
derived from the parentSelector
- the parentSelector annotation should be moved to the method that defines
the property. Also, we should prefix it with MSE and I would call it
ParentScope. So, something like this: FAMIXType>>container
<MSEProperty: #container type: #FAMIXContainerEntity opposite: #types>
<MSEComment: 'Container entity to which this type belongs to. Container is
a namespace, not a package (Smalltalk).'>
*<MSEParentScope>*
^container
We will try to do it now.
Cheers,
Anne & JC
2:43 p.m.
New subject: News about the new version of MooseChef and questions
Hi,
On Thu, Jul 30, 2015 at 2:30 PM, Jean-Christophe Bach <
jeanchristophe.bach(a)inria.fr> wrote:
We will try to do it.
Great.
As explained above, we disagree.
Thanks!
Doru
Hi,
We are not sure to understand. With MooseChef, if you work at class
level, you need to load pckgB because of classB. If you work at package
level, you do not see the dependency to pckgB and load only pckgC.
However pckgC cannot be loaded without pckgB (methodBExt1 cannot exist
if pckgB is not loaded). So, it is true that methodBExt1 directly
depends on only pckgC but it also depends indirectly on pckgB, which is
quite important to know. Without pckgB, classB does not exist and also
methodBExt1. MooseQuery has the advantage to be consistent when working
at class level or package level.
Consider that classA inherits from classX which is in packageX. ClassA
cannot exist without classX, but still you do not want this in the list of
dependencies. I think the same should apply to your case.
On the other hand, I think that we could still keep your behavior and when
we only want packageC, we could say:
*classA queryOutgoingInvocation atMethodScope atPackageScope ==> packageC*
I did not try. Would that be correct?
Very nice work. See more answers inline.
Thanks!
On Wed, Jul 29, 2015 at 4:14 PM, Anne Etien
<anne.etien(a)univ-lille1.fr>
wrote:
> Hi,
>
> We have improved MooseChef with a generic version MooseQuery.
> In the following when we talk about MooseChef, it means the current
> version available by default in Moose. When we talk about MooseQuery,
it
> means the generic improved version,
available on Anne’s smalltalkHub
> repository.
>
> All the tests of MooseChef except 4 are passing when using our new
> MooseQuery API.
> These four tests concern the same point package scope for extension
method.
>
> Considering classA having a method methodA1 calling a method
methodBExt1
> that extends classB.
> classB is defined in pckgB and its extension method by pckgC.
> Considering the two following requests:
> 1. classA queryOutgoingInvocation atClassScope atPackageScope
> 2. classA queryOutgoingInvocation atPackageScope
>
> To the first query, MooseChef and MooseQuery answer the same: pckgB
> To the second query, MooseChef answers pckgC and MooseQuery answers
pckgB
and
pckgC.
So first question: What is the expected behavior? What do we want?
According to us, MooseQuery behavior is more consistent.
In this example, the MooseChef is the more consistent one. Here is why.
at*Scope is applied to target entities (like opposites), not to
associations. In the second case, the associations point only to
methodBExt1. Thus, the expected at*Scope is applied on only methodBExt1
(and not to its class). This should be preserved.
Imagine that you would like to reason about dependencies between pckgA,
pckgB, and pckgC, and imagine that the contract we are looking for is to
only allow pckgA to depend on pckgC. Having a way to query that the
dependencies do not actually go to pckgB is quite important. I understand
how this can be difficult to implement in the current
implementation, given that for atPackageScope you depend on traversing
the
defined parentSelectors, but this is an important
issue and we should
find
a way to deal with it.
How about if there is a parentSelector that satisfies the condition for
the
current entity, we do not traverse further? So,
if you start from a
FAMIXMethod, you will stop because there is a parentPackage. What do you
think?
> ***************
> Considering now Java code.
> class1 contains a method method1 which in its turn contains an inner
class
> innerClass2. innerClass2 contains 2 methods
method21 and method22.
> the following query:
> innerClass2 methodScope
>
> In MooseChef this query has for result method21 and method22.
>
> The following query:
> innerClass2 atScope: FAMIXMethod
> In MooseQuery this query has for result method1. Indeed, the atScope:
> method look for the container (also called parent).
>
> So the second question: what is the expected behavior? Do we want like
in
> MooseQuery that atScope: by default always
goes up in the containment
tree
> since it is a generic version of
atTypeScope, atPackageScope... and do
we
> want another method to goes down in the
containment tree?
> In MooseChef, methodScope, always goes down to look for the contained
> methods. typeScope always goes up except for ScopingEntities. These
methods
have been
implemented for each type of entities. It is what we want to
avoid with MooseQuery.
Indeed, this semantics of at*Scope is confusing. It was tempting to do it
at the time, but since then I basically never used it, so we should
discard. And indeed, adding another operator like to*Scope would be both
simpler to understand and safer to use. ******************
>
> It is clear that Synectique will soon migrate to this new version and
that
> our project of SQL analysis will also use
it. Please don’t hesitate to
use
it.
MCHttpRepository
location: '
http://smalltalkhub.com/mc/AnneEtien/MooseQueryDraft/main'
user: ''
password: ‘'
We will do as soon as possible a small doc to explain the usage.
Thank you in advance for your answer to our questions.
So, I looked at the code a bit. We should integrate this as soon as
possible.
However, first we need to address a couple of issues:
- the traversing of parents like described above - there should be no need for the
<parentMetaClass:> annotation. This is
derived from the parentSelector
- the parentSelector annotation should be moved to the method that
defines
the property. Also, we should prefix it with MSE
and I would call it
ParentScope. So, something like this: FAMIXType>>container
<MSEProperty: #container type: #FAMIXContainerEntity opposite: #types>
<MSEComment: 'Container entity to which this type belongs to. Container
is
a namespace, not a package (Smalltalk).'>
*<MSEParentScope>*
^container
We will try to do it now.
Cheers,
Anne & JC
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
5:01 p.m.
Consider that classA inherits from classX which is in
packageX. ClassA
cannot exist without classX, but still you do not want this in the list of
dependencies. I think the same should apply to your case.
On the other hand, I think that we could still keep your behavior and when
we only want packageC, we could say:
*classA queryOutgoingInvocation atMethodScope atPackageScope ==> packageC*
I did not try. Would that be correct?
We tried and as expected it answers pckgB and pckgC.
We plan to keep this behaviour as the default one and to add another
filter to obtain only pckgC.
Anne & JC
2:49 p.m.
So, I looked
at the code a bit. We should integrate this as soon as
possible.
However, first we need to address a couple of issues:
- the traversing of parents like described above
As explained above, we disagree.
> - there should be no need for the <parentMetaClass:> annotation. This is
> derived from the parentSelector
> - the parentSelector annotation should be moved to the method that defines
> the property. Also, we should prefix it with MSE and I would call it
> ParentScope. So, something like this: FAMIXType>>container
> <MSEProperty: #container type: #FAMIXContainerEntity opposite: #types>
> <MSEComment: 'Container entity to which this type belongs to. Container is
> a namespace, not a package (Smalltalk).'>
> *<MSEParentScope>*
> ^container
3 p.m.
New subject: News about the new version of MooseChef and questions
Hi,
On Thu, Jul 30, 2015 at 2:49 PM, Jean-Christophe Bach <
jeanchristophe.bach(a)inria.fr> wrote:
is
We have to find a solution because I do not want to rely on strings :).
How about overriding the definition of parentPackage in FAMIXMethod?
FAMIXMethod>>parentPackage
"Package containing the entity in the code structure (if applicable)"
<MSEProperty: #parentPackage type: #FAMIXPackage opposite:
#childNamedEntities>
<MSEComment: 'Package containing the entity in the code structure (if
applicable)'>
*<MSEParentScope>*
^parentPackage
This would work I think.
The other question is why would we not allow the other subclasses to also
have a parentPackage as parent?
So, I looked at the code a bit. We should integrate
this as soon as
possible.
However, first we need to address a couple of issues:
- the traversing of parents like described above
As explained above, we disagree.
> - there should be no need for the <parentMetaClass:> annotation. This > derived from the parentSelector
> - the parentSelector annotation should be moved to the method that
defines
> the property. Also, we should prefix it with
MSE and I would call it
> ParentScope. So, something like this: FAMIXType>>container
> <MSEProperty: #container type: #FAMIXContainerEntity opposite: #types>
> <MSEComment: 'Container entity to which this type belongs to.
Container is
> a namespace, not a package
(Smalltalk).'>
> *<MSEParentScope>*
> ^container
We have just tried to do it. However it is not possible to move
parentSelector annotation to the method that defines the property.
Indeed, for example FAMIXClass and FAMIXMethod have two parentSelector
among which parentPackage that is inherited from FAMIXNamedEntity. For
the other classes inheriting from FAMIXNamedEntity parentPackage is not
a parentSelector. Therefore it is not possible to put the annotations on
the method itself.
Nevertheless, we will remove parentMetaClass
annotation as you
suggested.
Ok.
Doru
Anne & JC
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
5:29 p.m.
New subject: News about the new version of MooseChef and questions
On 30-07-15 17:03, Jean-Christophe Bach wrote:
There are a lot of languages that allow other nesting structures.
Stephan
We have to
find a solution because I do not want to rely on strings :).
How about overriding the definition of parentPackage in FAMIXMethod?
Perhaps a better solution would be to remove parentPackage from
FAMIXNamedEntity and to put it into FAMIXClass and FAMIXMethod.
31 Jul
31 Jul
9:02 a.m.
New subject: News about the new version of MooseChef and questions
Le 30 juil. 2015 à 17:29, stephan <stephan(a)stack.nl> a écrit :
On 30-07-15 17:03, Jean-Christophe Bach wrote:
There are a lot of languages that allow other nesting structures.
I am not
sure to right understand your remark. It is because the concept of Package does not exist
in any language that we suggested to move down parentPackage from FAMIXNamedEntity where
it is now to FAMIXClass and FAMIXMethod (since anyway, it is for these two concepts only
that the importers put values).
Moreover, the existence of other nesting structures is not a problem for the new API. For
this new API, you have to specify, currently in the annotation class method of each
FAMIXNamedEntity, what is its parent selectors. The atScope: method (and now also the
toScope:) relies on this pragma. Finally, if a function functionA is nested into another
functionB, the following query: functionA atScope: FAMIXFunction ==> functionA since it
is already a function.
One of the numerous reasons we initially developed MooseQuery was that I have a project of
SQL code analysis for which none of the existing MooseChef query worked. With MooseQuery,
you just have to add pragmas of the parent selectors and you can use all the power of the
requests.
Anne
We have
to find a solution because I do not want to rely on strings :).
How about overriding the definition of parentPackage in FAMIXMethod?
Perhaps a
better solution would be to remove parentPackage from
FAMIXNamedEntity and to put it into FAMIXClass and FAMIXMethod.
Stephan
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
30 Jul
30 Jul
3:20 p.m.
New subject: News about the new version of MooseChef and questions
On 29-07-15 16:14, Anne Etien wrote:
1. classA queryOutgoingInvocation atClassScope
atPackageScope
2. classA queryOutgoingInvocation atPackageScope
What exactly is atClassScope (or atTypeScope)? In FAMIX, a class is not
a scoping entity.
That only refers to global scopes. In other languages there are nested
functions and
methods.
Stephan
3:33 p.m.
* stephan <stephan(a)stack.nl> [30.07.2015. @15:20:48 +0200]:
On 29-07-15 16:14, Anne Etien wrote:
You are right: it is atTypeScope and not atClassScope. The name of the
selector is perhaps not correct but the idea is to navigate through the
containment tree and to give an answer filtered at the right level.
We could perhaps replace scope by level in the name of the selector.
Anne & JC
1. classA queryOutgoingInvocation atClassScope
atPackageScope
2. classA queryOutgoingInvocation atPackageScope
What exactly is atClassScope (or atTypeScope)? In FAMIX, a class is not
a scoping entity.
That only refers to global scopes. In other languages there are nested
functions and
methods.
3195
days inactive
3197
days old
11 comments
4 participants
participants (4)
-
Anne Etien -
Jean-Christophe Bach -
stephan -
Tudor Girba