Hi,

> Very nice work. See more answers inline.

Thanks!

> On Wed, Jul 29, 2015 at 4:14 PM, Anne Etien <anne.etien@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.

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.

> 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.

We will try to do it.

> ******************
> >
> > 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

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

We will try to do it now.

Cheers,

Anne & JC

_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev