Lift
Locked
 
|
Hi,
I developed a small extension which allows to query a moose model to obtain a set of implicit associations derived from low level relationships. What you can do concretely is for example to select a group of namespace entities, and ask for all implicit associations existing between the selected entities based on a specific relationship existing at a lower abstraction level (i.e.: the method level). The end result is much similar to the one provided by Moose Chef, with the advantage of being much more generic and flexible. Each generated association keeps a reference to the concrete relationships on which it is based on. If you are interested, you can try it out at: http://www.squeaksource.com/Lift.html The wiki page contains some usage examples. cheers, Andrea _____________________________ Software Composition Group University of Bern _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi Andrea,
It sounds quite cool. Unfortunately, squeaksource is down right now. I will try to review once it's up. Cheers, Doru On Mon, Jun 18, 2012 at 2:39 PM, Andrea Caracciolo <[hidden email]> wrote: > Hi, > > I developed a small extension which allows to query a moose model to obtain > a set of implicit associations derived from low level relationships. > What you can do concretely is for example to select a group of namespace > entities, and ask for all implicit associations existing between the > selected entities based on a specific relationship existing at a lower > abstraction level (i.e.: the method level). > The end result is much similar to the one provided by Moose Chef, with the > advantage of being much more generic and flexible. > Each generated association keeps a reference to the concrete relationships > on which it is based on. > > If you are interested, you can try it out > at: http://www.squeaksource.com/Lift.html > The wiki page contains some usage examples. > > cheers, > Andrea > > _____________________________ > Andrea Caracciolo -- [hidden email] > Software Composition Group > University of Bern > > _______________________________________________ > 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 |
|
|
Thanks for your interest.
Looking forward for your feedback. AC On Jun 18, 2012, at 4:32 PM, Tudor Girba wrote: > Hi Andrea, > > It sounds quite cool. Unfortunately, squeaksource is down right now. I > will try to review once it's up. > > Cheers, > Doru > > > On Mon, Jun 18, 2012 at 2:39 PM, Andrea Caracciolo > <[hidden email]> wrote: >> Hi, >> >> I developed a small extension which allows to query a moose model to obtain >> a set of implicit associations derived from low level relationships. >> What you can do concretely is for example to select a group of namespace >> entities, and ask for all implicit associations existing between the >> selected entities based on a specific relationship existing at a lower >> abstraction level (i.e.: the method level). >> The end result is much similar to the one provided by Moose Chef, with the >> advantage of being much more generic and flexible. >> Each generated association keeps a reference to the concrete relationships >> on which it is based on. >> >> If you are interested, you can try it out >> at: http://www.squeaksource.com/Lift.html >> The wiki page contains some usage examples. >> >> cheers, >> Andrea >> >> _____________________________ >> Andrea Caracciolo -- [hidden email] >> Software Composition Group >> University of Bern >> >> _______________________________________________ >> 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 |
|
|
In reply to this post by Andrea Caracciolo
Hi Andrea
This looks exciting! Especially since nicolas told me that it Moose def was cool :) Now I will wait that SS is up again. Stef On Jun 18, 2012, at 2:39 PM, Andrea Caracciolo wrote: > Hi, > > I developed a small extension which allows to query a moose model to obtain a set of implicit associations derived from low level relationships. > What you can do concretely is for example to select a group of namespace entities, and ask for all implicit associations existing between the selected entities based on a specific relationship existing at a lower abstraction level (i.e.: the method level). > The end result is much similar to the one provided by Moose Chef, with the advantage of being much more generic and flexible. > Each generated association keeps a reference to the concrete relationships on which it is based on. > > If you are interested, you can try it out at: http://www.squeaksource.com/Lift.html > The wiki page contains some usage examples. > > cheers, > Andrea > > _____________________________ > Andrea Caracciolo -- [hidden email] > Software Composition Group > University of Bern > _______________________________________________ > 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 |
|
|
In reply to this post by Andrea Caracciolo
Hk Andrea,
I had a quick look at Lift. Being able to express the queries on MooseGroups is a nice addon. But I think it would have been much nicer keeping the syntax of MooseChef. Instead of: (aNamespaceGroup lift: #incomingInvocations from:self mooseModel allMethods) asMooseGroup why don't you use: aNamespaceGroup queryIncomingInvocations atNamespaceScope which according to MooseChef syntax should return the same thing ? I trust you will agree the second is more elegant , and it has the advantage of keeping the same syntax, so we don't need to learn a new syntax nicolas On 18/06/12 14:39, Andrea Caracciolo wrote: Hi, _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi Nicolas,
You are right, the syntax of moose chef is more elegant. But the point of creating a new extension was to offer the option to express more generic queries. If you are working on a moose model which represents a Java program, you can easily use moose chef and get what you need. But if the model you are analyzing is of a different kind (a famix extension or a generic moose model) and provides unforseen selectors and entities, what can you do ? You have to look at Lift as a less domain-bound version of chef, not necessarily as a chef replacement. Did i understand your question correctly ? Does it make sense to you ? Andrea On Jun 19, 2012, at 11:06 AM, Nicolas Anquetil wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Nicolas Anquetil
Hi Nicolas,
I am not sure I understand your concern. The idea behind Lift is not to reimplement MooseChef, but to offer a quick way to infer these relationships on other entities than regular FAMIX ones. Cheers, Doru On Tue, Jun 19, 2012 at 11:06 AM, Nicolas Anquetil <[hidden email]> wrote: > Hk Andrea, > > I had a quick look at Lift. > Being able to express the queries on MooseGroups is a nice addon. > > But I think it would have been much nicer keeping the syntax of MooseChef. > > Instead of: > > (aNamespaceGroup lift: #incomingInvocations from:self mooseModel allMethods) > asMooseGroup > > why don't you use: > > aNamespaceGroup queryIncomingInvocations atNamespaceScope > > which according to MooseChef syntax should return the same thing ? > > I trust you will agree the second is more elegant , and it has the advantage > of keeping the same syntax, so we don't need to learn a new syntax > > nicolas > > > On 18/06/12 14:39, Andrea Caracciolo wrote: > > Hi, > > I developed a small extension which allows to query a moose model to obtain > a set of implicit associations derived from low level relationships. > What you can do concretely is for example to select a group of namespace > entities, and ask for all implicit associations existing between the > selected entities based on a specific relationship existing at a lower > abstraction level (i.e.: the method level). > The end result is much similar to the one provided by Moose Chef, with the > advantage of being much more generic and flexible. > Each generated association keeps a reference to the concrete relationships > on which it is based on. > > If you are interested, you can try it out > at: http://www.squeaksource.com/Lift.html > The wiki page contains some usage examples. > > cheers, > Andrea > > _____________________________ > Andrea Caracciolo -- [hidden email] > Software Composition Group > University of Bern > > > _______________________________________________ > 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 |
|
|
In reply to this post by Andrea Caracciolo
Hi Andrea, (and doru incidently) The "more generic" part of your goal was not explicited in the previous email, so the mention of moosechef and the examples, led me on a wrong path. you can safely ignore my previous comment :-) Now, keeping an analogy with MooseChef, it implements thing that you might want to consider (at this level of abstraction it's a bit hard to tell): - relation vs. entities can you filter the results to return either the relationships or the entities they relate? Is that what 'asMooseGroup' is doing? If so you might want to consider some other name (eg 'asEntities') - relation roles MooseChef allows to request either the 'to' or 'from' end of an association, can you similarly specify the 'selector1' or 'selector2' (or 'selector3', ...) roles of your generic relationship? - scoping Can you restrict the resulting entities/relationship to be of a given type? as we are at a very abstract level, it might be better to offer a filterBlock and let the user define what kind of filter he whishes to apply? nicolas PS: I had a glance at your code. The mehtods look suspiciously long for a smalltalk implementation ... De: "Andrea Caracciolo" <[hidden email]> _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
<base href="x-msg://512/">
Hi Nicolas, 1) the asMooseGroup is just a standard moose method used to convert a collection into a MooseGroup object. I will probably move it in the lift:from: method. No filtering option is currently supported. What you get right now are objects of type FAMIXLiftedAssociation representing inferred associations. These objects have a reference to the source and target high level entities they connect and to the low level concrete associations which they abstract. One possible extension (as you suggested) could be adding the following method: lift: aSelector from: aMooseGroup filter: aBlock and some shortcuts like: lift: aSelector from: aMooseGroup sourceEntities --> aBlock := [:each | each from] lift: aSelector from: aMooseGroup targetEntities --> aBlock := [:each | each to] 2) is point one answering your question ? 3) I'm not sure i understand your question. Scoping is implicitly defined by the entities contained in the MooseGroup on which the query is executed and the MooseGroup specified in the from parameter. This means that if you execute: highLevelGroup := MooseModel root first allNamespaces. lowLevelGroup := MooseModel root first allMethods. (highLevelGroup lift: #incomingInvocations from:lowLevelGroup) asMooseGroup. you will get a set of associations connecting namespaces (high level scope) and these associations will abstract concrete association existing between entities of type method (low level scope). I hope i answered your question. Let me know what you think about. cheers, Andrea On Jun 19, 2012, at 2:44 PM, Nicolas Anquetil wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
On 19/06/12 17:10, Andrea Caracciolo wrote:
<base href="x-msg://512/">Yes. However take care that you are implicitly restricting your relationships to be binary and directed (from/to) What if I want a "sibling" relationship? It might be implemented in a way that contradict your hypotheses. The roles might have different names than to/from and it could be interesting (or not) to take this into account just as you have "lift: aSelector" This could mean that instead of returning a collection of FAMIXLiftedAssociation, you would return a LiftedResult that would contain a collection of "normal relationships" (whatever they are). The second way is how mooseChef treats the result of its queries. Currently you always return relationships, so scoping might be less important (still ...) But if we come back to my first point, then it changes a lot. If MooseChef sensed the need to return either associations or entities, it might be an indication that you could need it too (again reasoning completely abstractly ids difficult, it would depend on the exact use cases). And if you allow returning entities, then scoping can become important: when I want all incoming invocation to a package, I might want the invocations themselves, or the packages they originate from, or the classes, or the methods, ... thus scoping. It might also be that one relationship may have different to or from entities. Consider for example FamixReferences that might originate from a method or from a class and target, variables, parameters, or attributes. I might be interested only in the references to attributes and coming from classes ... I don't know how general you want to be so I am reasonning at the most generic level I can manage. Finally, you always give example of queries on moosegroups, did you exclude queries on single MooseEntity? (Not that it would change much to the discussion, only to the implementation) nicolas
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi,
2012/6/19 Nicolas Anquetil <[hidden email]>
Sorry Nicolas but I don't follow you. All the relations in Moose are binary: any relation is just among two entities. If I have a one to many relation than I will have multiple relation objects with the same sender and different receivers. Also the lift relation it is not necessarily directed. It is the rationale that makes it directed or not. From and to don't have to mean that the relation goes from the from part and goes to the to part. An attribute that specify if the lift relation is directed or not could be useful to distinguish the case.
quite impossible to return normal relations since Lift infers and returns relations that do not exist. The rest of your email about helper methods to return directly the models could make sense in some cases.
A query to a moosegroup of one entity is it not the same? Cheers, Fabrizio _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
On Jun 19, 2012, at 7:30 PM, Fabrizio Perin wrote: > Hi, > > 2012/6/19 Nicolas Anquetil <[hidden email]> > On 19/06/12 17:10, Andrea Caracciolo wrote: > Yes. > However take care that you are implicitly restricting your relationships to be binary and directed (from/to) > What if I want a "sibling" relationship? > > Sorry Nicolas but I don't follow you. All the relations in Moose are binary: any relation is just among two entities. If I have a one to many relation than I will have multiple relation objects with the same sender and different receivers. Also the lift relation it is not necessarily directed. It is the rationale that makes it directed or not. From and to don't have to mean that the relation goes from the from part and goes to the to part. An attribute that specify if the lift relation is directed or not could be useful to distinguish the case. Hi fabrizio Multiple inheritance is managed as different relationships? I do not remember :) > > It might be implemented in a way that contradict your hypotheses. > > The roles might have different names than to/from and it could be interesting (or not) to take this into account just as you have "lift: aSelector" > This could mean that instead of returning a collection of FAMIXLiftedAssociation, you would return a LiftedResult that would contain a collection of "normal relationships" (whatever they are). > > quite impossible to return normal relations since Lift infers and returns relations that do not exist. but may be you do not have to wrap all your results in LifAssociations and can have mixed results with famix and lift associations ? > > The rest of your email about helper methods to return directly the models could make sense in some cases. > > Finally, you always give example of queries on moosegroups, did you exclude queries on single MooseEntity? > > A query to a moosegroup of one entity is it not the same? > > Cheers, > Fabrizio > _______________________________________________ > 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 |
|
|
Lift was initially born to materialize implicit relationships derived from low level associations.
Moose chef is a query engine for famix models. This means that it analyses a given model and returns only concrete associations. What i understand from your comments is that you would like to port some of the querying functionalities offered by chef to lift. I tried to make up a list of possible requirements: - query concrete associations by applying a selector on an entity/group # in chef: aMethod queryAllIncomingInvocations - query concrete associations by applying a selector on entities contained in the receiver entity/group # in chef: aNamespace queryAllIncomingInvocations - query inferred associations by applying a selector on entities contained in the receiver entity/group # in chef: not supported - filter returned associations by applying a custom select block - filter returned associations by source/target class type - filter returned associations by target scope (e.g: target entity must be within anEntity/aGroup) # in chef: aMethod queryOutgoingReferences opposites withinPackage: aPackage - transform returned associations by applying a custom collect block - transform each returned association to its source/target entity # in chef: aMethod queryAllIncomingInvocations opposites - return entities of a specified class type containing the "to" part of the returned associations # in chef: aMethod queryOutgoingReferences atPackageScope Are they correct ? is the list complete ? > but may be you do not have to wrap all your results in LifAssociations and can have mixed results with famix and lift associations It's already like this. concrete low level associations are usually (when possible) taken as is. If you execute: (self lift: #incomingInvocations from:self mooseModel allMethods) asMooseGroup. You will see that the subassociations are of type FAMIXInvocation. > However take care that you are implicitly restricting your relationships to be binary and directed (from/to) > What if I want a "sibling" relationship? You are right. My supposition is that all the associations are one-to-one. FAMIXAssociation has a "from" and a "to" field. How would you handle one-to-many associations ? If you pass the selector to the specified receiver and you get multiple entities would you treat it as a one-to-many association ? "to" and "from", as fabrizio said, do not have any predefined semantic. They just follow the direction of the selector (from is the message reciever and to is the result). > Finally, you always give example of queries on moosegroups, did you exclude queries on single MooseEntity? I will soon add support for mooseEntities too. Cheers, Andrea On Jun 20, 2012, at 9:57 AM, Stéphane Ducasse wrote: > > On Jun 19, 2012, at 7:30 PM, Fabrizio Perin wrote: > >> Hi, >> >> 2012/6/19 Nicolas Anquetil <[hidden email]> >> On 19/06/12 17:10, Andrea Caracciolo wrote: >> Yes. >> However take care that you are implicitly restricting your relationships to be binary and directed (from/to) >> What if I want a "sibling" relationship? >> >> Sorry Nicolas but I don't follow you. All the relations in Moose are binary: any relation is just among two entities. If I have a one to many relation than I will have multiple relation objects with the same sender and different receivers. Also the lift relation it is not necessarily directed. It is the rationale that makes it directed or not. From and to don't have to mean that the relation goes from the from part and goes to the to part. An attribute that specify if the lift relation is directed or not could be useful to distinguish the case. > > Hi fabrizio > Multiple inheritance is managed as different relationships? I do not remember :) > >> >> It might be implemented in a way that contradict your hypotheses. >> >> The roles might have different names than to/from and it could be interesting (or not) to take this into account just as you have "lift: aSelector" >> This could mean that instead of returning a collection of FAMIXLiftedAssociation, you would return a LiftedResult that would contain a collection of "normal relationships" (whatever they are). >> >> quite impossible to return normal relations since Lift infers and returns relations that do not exist. > > but may be you do not have to wrap all your results in LifAssociations and can have mixed results with famix and lift associations > ? > > >> >> The rest of your email about helper methods to return directly the models could make sense in some cases. >> >> Finally, you always give example of queries on moosegroups, did you exclude queries on single MooseEntity? >> >> A query to a moosegroup of one entity is it not the same? >> >> Cheers, >> Fabrizio >> _______________________________________________ >> 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 |
|
|
don't get me wrong, I am not asking for anything.
I don't know exactly what is your ultimate goal, so I am merely brainstorming. Since I have no concrete application case (what is the concrete problem?) I am using moose chef as inspiration. nicolas On 20/06/12 14:04, Andrea Caracciolo wrote: > Lift was initially born to materialize implicit relationships derived from low level associations. > Moose chef is a query engine for famix models. This means that it analyses a given model and returns only concrete associations. > What i understand from your comments is that you would like to port some of the querying functionalities offered by chef to lift. > > I tried to make up a list of possible requirements: > - query concrete associations by applying a selector on an entity/group > # in chef: aMethod queryAllIncomingInvocations > - query concrete associations by applying a selector on entities contained in the receiver entity/group > # in chef: aNamespace queryAllIncomingInvocations > - query inferred associations by applying a selector on entities contained in the receiver entity/group > # in chef: not supported > - filter returned associations by applying a custom select block > - filter returned associations by source/target class type > - filter returned associations by target scope (e.g: target entity must be within anEntity/aGroup) > # in chef: aMethod queryOutgoingReferences opposites withinPackage: aPackage > - transform returned associations by applying a custom collect block > - transform each returned association to its source/target entity > # in chef: aMethod queryAllIncomingInvocations opposites > - return entities of a specified class type containing the "to" part of the returned associations > # in chef: aMethod queryOutgoingReferences atPackageScope > > Are they correct ? is the list complete ? > >> but may be you do not have to wrap all your results in LifAssociations and can have mixed results with famix and lift associations > It's already like this. concrete low level associations are usually (when possible) taken as is. > If you execute: (self lift: #incomingInvocations from:self mooseModel allMethods) asMooseGroup. > You will see that the subassociations are of type FAMIXInvocation. > >> However take care that you are implicitly restricting your relationships to be binary and directed (from/to) >> What if I want a "sibling" relationship? > You are right. My supposition is that all the associations are one-to-one. FAMIXAssociation has a "from" and a "to" field. > How would you handle one-to-many associations ? > If you pass the selector to the specified receiver and you get multiple entities would you treat it as a one-to-many association ? > "to" and "from", as fabrizio said, do not have any predefined semantic. They just follow the direction of the selector (from is the message reciever and to is the result). > >> Finally, you always give example of queries on moosegroups, did you exclude queries on single MooseEntity? > I will soon add support for mooseEntities too. > > Cheers, > Andrea > > On Jun 20, 2012, at 9:57 AM, Stéphane Ducasse wrote: > >> On Jun 19, 2012, at 7:30 PM, Fabrizio Perin wrote: >> >>> Hi, >>> >>> 2012/6/19 Nicolas Anquetil<[hidden email]> >>> On 19/06/12 17:10, Andrea Caracciolo wrote: >>> Yes. >>> However take care that you are implicitly restricting your relationships to be binary and directed (from/to) >>> What if I want a "sibling" relationship? >>> >>> Sorry Nicolas but I don't follow you. All the relations in Moose are binary: any relation is just among two entities. If I have a one to many relation than I will have multiple relation objects with the same sender and different receivers. Also the lift relation it is not necessarily directed. It is the rationale that makes it directed or not. From and to don't have to mean that the relation goes from the from part and goes to the to part. An attribute that specify if the lift relation is directed or not could be useful to distinguish the case. >> Hi fabrizio >> Multiple inheritance is managed as different relationships? I do not remember :) >> >>> It might be implemented in a way that contradict your hypotheses. >>> >>> The roles might have different names than to/from and it could be interesting (or not) to take this into account just as you have "lift: aSelector" >>> This could mean that instead of returning a collection of FAMIXLiftedAssociation, you would return a LiftedResult that would contain a collection of "normal relationships" (whatever they are). >>> >>> quite impossible to return normal relations since Lift infers and returns relations that do not exist. >> but may be you do not have to wrap all your results in LifAssociations and can have mixed results with famix and lift associations >> ? >> >> >>> The rest of your email about helper methods to return directly the models could make sense in some cases. >>> >>> Finally, you always give example of queries on moosegroups, did you exclude queries on single MooseEntity? >>> >>> A query to a moosegroup of one entity is it not the same? >>> >>> Cheers, >>> Fabrizio >>> _______________________________________________ >>> 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 _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
I'm glad to receive feedback and i appreciate new ideas.
I see that there is a lot of room for improvement and would like to see what else can be done. This first release is just a starting point, and the reason i shared it on this mailing list was exactly to get some input from people who could possibly be interested in using it. the goal is to build a generic and flexible non-FAMIX-specific query engine which allows to obtain both implicit and explicit associations. Chef is tightly coupled to famix, its query methods are hard coded and the query set is quite limited and not easily extensible. Some concrete use cases: - query inferred relationships at the top of the entity hierarchy level (could be useful for having a more abstract overview of the overall program dependencies at package level) - query a custom model in moose - query a famix model enriched with custom defined selectors or associations if you could give me some feedback about the requirements list it would be great. cheers, Andrea On Jun 20, 2012, at 3:31 PM, Nicolas Anquetil wrote: > don't get me wrong, I am not asking for anything. > I don't know exactly what is your ultimate goal, so I am merely brainstorming. > > Since I have no concrete application case (what is the concrete problem?) I am using moose chef as inspiration. > > nicolas > > > On 20/06/12 14:04, Andrea Caracciolo wrote: >> Lift was initially born to materialize implicit relationships derived from low level associations. >> Moose chef is a query engine for famix models. This means that it analyses a given model and returns only concrete associations. >> What i understand from your comments is that you would like to port some of the querying functionalities offered by chef to lift. >> >> I tried to make up a list of possible requirements: >> - query concrete associations by applying a selector on an entity/group >> # in chef: aMethod queryAllIncomingInvocations >> - query concrete associations by applying a selector on entities contained in the receiver entity/group >> # in chef: aNamespace queryAllIncomingInvocations >> - query inferred associations by applying a selector on entities contained in the receiver entity/group >> # in chef: not supported >> - filter returned associations by applying a custom select block >> - filter returned associations by source/target class type >> - filter returned associations by target scope (e.g: target entity must be within anEntity/aGroup) >> # in chef: aMethod queryOutgoingReferences opposites withinPackage: aPackage >> - transform returned associations by applying a custom collect block >> - transform each returned association to its source/target entity >> # in chef: aMethod queryAllIncomingInvocations opposites >> - return entities of a specified class type containing the "to" part of the returned associations >> # in chef: aMethod queryOutgoingReferences atPackageScope >> >> Are they correct ? is the list complete ? >> >>> but may be you do not have to wrap all your results in LifAssociations and can have mixed results with famix and lift associations >> It's already like this. concrete low level associations are usually (when possible) taken as is. >> If you execute: (self lift: #incomingInvocations from:self mooseModel allMethods) asMooseGroup. >> You will see that the subassociations are of type FAMIXInvocation. >> >>> However take care that you are implicitly restricting your relationships to be binary and directed (from/to) >>> What if I want a "sibling" relationship? >> You are right. My supposition is that all the associations are one-to-one. FAMIXAssociation has a "from" and a "to" field. >> How would you handle one-to-many associations ? >> If you pass the selector to the specified receiver and you get multiple entities would you treat it as a one-to-many association ? >> "to" and "from", as fabrizio said, do not have any predefined semantic. They just follow the direction of the selector (from is the message reciever and to is the result). >> >>> Finally, you always give example of queries on moosegroups, did you exclude queries on single MooseEntity? >> I will soon add support for mooseEntities too. >> >> Cheers, >> Andrea >> >> On Jun 20, 2012, at 9:57 AM, Stéphane Ducasse wrote: >> >>> On Jun 19, 2012, at 7:30 PM, Fabrizio Perin wrote: >>> >>>> Hi, >>>> >>>> 2012/6/19 Nicolas Anquetil<[hidden email]> >>>> On 19/06/12 17:10, Andrea Caracciolo wrote: >>>> Yes. >>>> However take care that you are implicitly restricting your relationships to be binary and directed (from/to) >>>> What if I want a "sibling" relationship? >>>> >>>> Sorry Nicolas but I don't follow you. All the relations in Moose are binary: any relation is just among two entities. If I have a one to many relation than I will have multiple relation objects with the same sender and different receivers. Also the lift relation it is not necessarily directed. It is the rationale that makes it directed or not. From and to don't have to mean that the relation goes from the from part and goes to the to part. An attribute that specify if the lift relation is directed or not could be useful to distinguish the case. >>> Hi fabrizio >>> Multiple inheritance is managed as different relationships? I do not remember :) >>> >>>> It might be implemented in a way that contradict your hypotheses. >>>> >>>> The roles might have different names than to/from and it could be interesting (or not) to take this into account just as you have "lift: aSelector" >>>> This could mean that instead of returning a collection of FAMIXLiftedAssociation, you would return a LiftedResult that would contain a collection of "normal relationships" (whatever they are). >>>> >>>> quite impossible to return normal relations since Lift infers and returns relations that do not exist. >>> but may be you do not have to wrap all your results in LifAssociations and can have mixed results with famix and lift associations >>> ? >>> >>> >>>> The rest of your email about helper methods to return directly the models could make sense in some cases. >>>> >>>> Finally, you always give example of queries on moosegroups, did you exclude queries on single MooseEntity? >>>> >>>> A query to a moosegroup of one entity is it not the same? >>>> >>>> Cheers, >>>> Fabrizio >>>> _______________________________________________ >>>> 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 > > _______________________________________________ > 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 |
|
|
In reply to this post by Andrea Caracciolo
> Moose chef is a query engine for famix models. This means that it analyses a given model and returns only concrete associations.
> What i understand from your comments is that you would like to port some of the querying functionalities offered by chef to lift. > > I tried to make up a list of possible requirements: > - query concrete associations by applying a selector on an entity/group > # in chef: aMethod queryAllIncomingInvocations > - query concrete associations by applying a selector on entities contained in the receiver entity/group > # in chef: aNamespace queryAllIncomingInvocations > - query inferred associations by applying a selector on entities contained in the receiver entity/group > # in chef: not supported > - filter returned associations by applying a custom select block > - filter returned associations by source/target class type > - filter returned associations by target scope (e.g: target entity must be within anEntity/aGroup) > # in chef: aMethod queryOutgoingReferences opposites withinPackage: aPackage > - transform returned associations by applying a custom collect block > - transform each returned association to its source/target entity > # in chef: aMethod queryAllIncomingInvocations opposites > - return entities of a specified class type containing the "to" part of the returned associations > # in chef: aMethod queryOutgoingReferences atPackageScope > > Are they correct ? is the list complete ? > >> but may be you do not have to wrap all your results in LifAssociations and can have mixed results with famix and lift associations > It's already like this. concrete low level associations are usually (when possible) taken as is. > If you execute: (self lift: #incomingInvocations from:self mooseModel allMethods) asMooseGroup. > You will see that the subassociations are of type FAMIXInvocation. Good then. > >> However take care that you are implicitly restricting your relationships to be binary and directed (from/to) >> What if I want a "sibling" relationship? > You are right. My supposition is that all the associations are one-to-one. FAMIXAssociation has a "from" and a "to" field. > How would you handle one-to-many associations ? > If you pass the selector to the specified receiver and you get multiple entities would you treat it as a one-to-many association ? > "to" and "from", as fabrizio said, do not have any predefined semantic. They just follow the direction of the selector (from is the message reciever and to is the result). > >> Finally, you always give example of queries on moosegroups, did you exclude queries on single MooseEntity? > I will soon add support for mooseEntities too. > > Cheers, > Andrea > > On Jun 20, 2012, at 9:57 AM, Stéphane Ducasse wrote: > >> >> On Jun 19, 2012, at 7:30 PM, Fabrizio Perin wrote: >> >>> Hi, >>> >>> 2012/6/19 Nicolas Anquetil <[hidden email]> >>> On 19/06/12 17:10, Andrea Caracciolo wrote: >>> Yes. >>> However take care that you are implicitly restricting your relationships to be binary and directed (from/to) >>> What if I want a "sibling" relationship? >>> >>> Sorry Nicolas but I don't follow you. All the relations in Moose are binary: any relation is just among two entities. If I have a one to many relation than I will have multiple relation objects with the same sender and different receivers. Also the lift relation it is not necessarily directed. It is the rationale that makes it directed or not. From and to don't have to mean that the relation goes from the from part and goes to the to part. An attribute that specify if the lift relation is directed or not could be useful to distinguish the case. >> >> Hi fabrizio >> Multiple inheritance is managed as different relationships? I do not remember :) >> >>> >>> It might be implemented in a way that contradict your hypotheses. >>> >>> The roles might have different names than to/from and it could be interesting (or not) to take this into account just as you have "lift: aSelector" >>> This could mean that instead of returning a collection of FAMIXLiftedAssociation, you would return a LiftedResult that would contain a collection of "normal relationships" (whatever they are). >>> >>> quite impossible to return normal relations since Lift infers and returns relations that do not exist. >> >> but may be you do not have to wrap all your results in LifAssociations and can have mixed results with famix and lift associations >> ? >> >> >>> >>> The rest of your email about helper methods to return directly the models could make sense in some cases. >>> >>> Finally, you always give example of queries on moosegroups, did you exclude queries on single MooseEntity? >>> >>> A query to a moosegroup of one entity is it not the same? >>> >>> Cheers, >>> Fabrizio >>> _______________________________________________ >>> 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 _______________________________________________ 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 |