Hi doru is there a way to convert a model into a group? Stef _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Me, I understood :) Currently you can not do what you want. Please go ahead and fix this! It would be nice to have all those "all of kind" selectors like allClasses on both Model and Group instead of Model only. Maybe we can make a common superclass for Group and Model to fix that, if not ... dream of traits and implement it using a state / strategy / delegator pattern. Also when you are fixing this, please also fix that annoying fact that these "all of kind" selectors have to be meta-described and implemented by hand. It would be much nice if the Model and Group provide automatically an "all of kind" selector for each available MetaDescription. cheers, AA On 30 Nov 2007, at 16:01 , Tudor Girba wrote: > Hi, > > Hmm. That is an interesting question, but I am not sure about the use > case. > > At this moment, groups are targeted to modeling behavior for known > types of elements. That is if you have a collection of classes we > define the behavior in ClassGroup. > > On the other hand, a model is made for storage, and for providing a > start for navigation. > > It seems to me like what you want is to take a model and the > filtering > result to be another model instead of group. But, I did not > understand exactly what the use case is. Could you elaborate some > more? > > Doru > > On Nov 30, 2007, at 2:27 PM, stephane ducasse wrote: > >> Hi doru >> >> is there a way to convert a model into a group? >> >> Stef >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "Yesterday is a fact. > Tomorrow is a possibility. > Today is a challenge." > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Me, I understood :) Currently you can not do what you want. Please go ahead and fix this! It would be nice to have all those "all of kind" selectors like allClasses on both Model and Group instead of Model only.

Maybe we can make a common superclass for Group and Model to fix that, if not ... dream of traits and implement it using a state / strategy / delegator pattern.

Also when you are fixing this, please also fix that annoying fact that these "all of kind" selectors have to be meta-described and implemented by hand. It would be much nice if the Model and Group provide automatically an "all of kind" selector for each available MetaDescription.

cheers, AA On 30 Nov 2007, at 16:01 , Tudor Girba wrote: > Hi, > > Hmm. That is an interesting question, but I am not sure about the use > case. > > At this moment, groups are targeted to modeling behavior for known > types of elements. That is if you have a collection of classes we > define the behavior in ClassGroup. > > On the other hand, a model is made for storage, and for providing a > start for navigation. > > It seems to me like what you want is to take a model and the > filtering > result to be another model instead of group. But, I did not > understand exactly what the use case is. Could you elaborate some > more? > > Doru > > On Nov 30, 2007, at 2:27 PM, stephane ducasse wrote: > >> Hi doru >> >> is there a way to convert a model into a group? >> >> Stef >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "Yesterday is a fact. > Tomorrow is a possibility. > Today is a challenge." > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On 2 déc. 07, at 10:32, Tudor Girba wrote: > Perhaps it is just obvious, but I would still want to know about the > use case. > > If you would have a Group with 2 packages (P1 and P2) inside, what > would allClasses return: > 1. empty collection, because there is no class inside the group > 2. total classes from P1 and P2 > 3. allClasses from the overall model? > > In the same way, if you would have just 1 method (C1>>M1) and a class > (C2) inside a group, what would allClasses return: > 1. a collection with C2 > 2. a collection with C1 and C2 > 3. allClasses from the overall model? > > I would tend to go for option 1. even for case One above? why not. For now my scenario is a stream of models obtained using a filter mechanism. If I want to merge two groupPackage I just add them to a third one. > In this case it would make sense to > make Group and Model be similar, the difference being that adding an > entity in a Model sets the mooseModel in the entity, while when you > add it in an entity, it leaves mooseModel untouched. Yes this would be good > If it is option 2, it can just be that what you actually want is to > have a very specific structure that is not a generic group, but that > has some meaning and specific behavior for your case. > > If it is option 3, then you can always just add in your code: self > mooseModel allClasses. Ok so this means that I want option 1. Because I only want the part that I selected. > I waited for quite some time for someone to actually have a use case > for such groups that are heterogeneous, and I would appreciate the > time to talk a bit about it. I have one. We want to build views of models based on filter combination. > > > Doru > > > On Nov 30, 2007, at 5:24 PM, Adrian Kuhn wrote: > >> Me, I understood :) >> >> Currently you can not do what you want. Please go ahead and fix >> this! >> >> It would be nice to have all those "all of kind" selectors like >> allClasses on both Model and Group instead of Model only. Maybe we >> can make a common superclass for Group and Model to fix that, if >> not ... dream of traits and implement it using a state / strategy / >> delegator pattern. >> >> Also when you are fixing this, please also fix that annoying fact >> that these "all of kind" selectors have to be meta-described and >> implemented by hand. It would be much nice if the Model and Group >> provide automatically an "all of kind" selector for each available >> MetaDescription. >> >> cheers, >> AA >> >> >> >> >> >> >> On 30 Nov 2007, at 16:01 , Tudor Girba wrote: >> >>> Hi, >>> >>> Hmm. That is an interesting question, but I am not sure about the >>> use >>> case. >>> >>> At this moment, groups are targeted to modeling behavior for known >>> types of elements. That is if you have a collection of classes we >>> define the behavior in ClassGroup. >>> >>> On the other hand, a model is made for storage, and for providing a >>> start for navigation. >>> >>> It seems to me like what you want is to take a model and the >>> filtering >>> result to be another model instead of group. But, I did not >>> understand exactly what the use case is. Could you elaborate some >>> more? >>> >>> Doru >>> >>> On Nov 30, 2007, at 2:27 PM, stephane ducasse wrote: >>> >>>> Hi doru >>>> >>>> is there a way to convert a model into a group? >>>> >>>> Stef >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> www.tudorgirba.com/blog >>> >>> "Yesterday is a fact. >>> Tomorrow is a possibility. >>> Today is a challenge." >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "Problem solving efficiency grows with the abstractness level of > problem understanding." > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

I put up an implementation. Basically I put MooseModel as subclass of AbstractGroup and moved the storage behavior from MooseModel to AbstractGroup: AbstractGroup <-- MooseModel <-- Group AbstractGroup was anyway something bothering me for quite some time because it only had one subclass (Group), but now it feels better cause it has 2 :). Anyway, now I guess the name of AbstractGroup is not really matching. Also, I am also unsure now if the EntityStorage implementation is overkill for the needs of the Group. So, feedback is welcome :). If you want to take a look try 3.2.73.girba.1. I put it in a branch and marked it as work in progress because there are still some tests failing. Take a look at GroupTest>>testAllLikeSelectors for usage examples. For example, if you really want to, now you can use: (model allClasses, model allMethods) allClasses I am still curios how we are going to put it to a good practice :) Cheers, Doru On Dec 3, 2007, at 11:54 PM, Tudor Girba wrote: > Ok, I will do it like that. This implies that Group and Model will > share the storage implementation. > > Actually, I had a use case long time ago: in CodeCrawler I could > select any node (e.g. class) and edge (e.g. inheritance) and then > obtain a submenu for each subgroup type. > > Doru > > On Dec 3, 2007, at 12:34 PM, Stéphane Ducasse wrote: > >> >> On 2 déc. 07, at 10:32, Tudor Girba wrote: >> >>> Perhaps it is just obvious, but I would still want to know about >>> the >>> use case. >>> >>> If you would have a Group with 2 packages (P1 and P2) inside, what >>> would allClasses return: >>> 1. empty collection, because there is no class inside the group >>> 2. total classes from P1 and P2 >>> 3. allClasses from the overall model? >>> >>> In the same way, if you would have just 1 method (C1>>M1) and a >>> class >>> (C2) inside a group, what would allClasses return: >>> 1. a collection with C2 >>> 2. a collection with C1 and C2 >>> 3. allClasses from the overall model? >>> >>> I would tend to go for option 1. >> >> even for case One above? why not. >> >> For now my scenario is a stream of models obtained using a filter >> mechanism. >> If I want to merge two groupPackage I just add them to a third one. >> >>> In this case it would make sense to >>> make Group and Model be similar, the difference being that >>> adding an >>> entity in a Model sets the mooseModel in the entity, while when you >>> add it in an entity, it leaves mooseModel untouched. >> >> Yes this would be good >> >>> If it is option 2, it can just be that what you actually want is to >>> have a very specific structure that is not a generic group, but >>> that >>> has some meaning and specific behavior for your case. >>> >>> If it is option 3, then you can always just add in your code: self >>> mooseModel allClasses. >> >> Ok so this means that I want option 1. Because I only want the part >> that I selected. >> >>> I waited for quite some time for someone to actually have a use >>> case >>> for such groups that are heterogeneous, and I would appreciate the >>> time to talk a bit about it. >> >> I have one. >> We want to build views of models based on filter combination. >>> >>> >>> Doru >>> >>> >>> On Nov 30, 2007, at 5:24 PM, Adrian Kuhn wrote: >>> >>>> Me, I understood :) >>>> >>>> Currently you can not do what you want. Please go ahead and fix >>>> this! >>>> >>>> It would be nice to have all those "all of kind" selectors like >>>> allClasses on both Model and Group instead of Model only. Maybe we >>>> can make a common superclass for Group and Model to fix that, if >>>> not ... dream of traits and implement it using a state / >>>> strategy / >>>> delegator pattern. >>>> >>>> Also when you are fixing this, please also fix that annoying fact >>>> that these "all of kind" selectors have to be meta-described and >>>> implemented by hand. It would be much nice if the Model and Group >>>> provide automatically an "all of kind" selector for each available >>>> MetaDescription. >>>> >>>> cheers, >>>> AA >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 30 Nov 2007, at 16:01 , Tudor Girba wrote: >>>> >>>>> Hi, >>>>> >>>>> Hmm. That is an interesting question, but I am not sure about the >>>>> use >>>>> case. >>>>> >>>>> At this moment, groups are targeted to modeling behavior for >>>>> known >>>>> types of elements. That is if you have a collection of classes we >>>>> define the behavior in ClassGroup. >>>>> >>>>> On the other hand, a model is made for storage, and for >>>>> providing a >>>>> start for navigation. >>>>> >>>>> It seems to me like what you want is to take a model and the >>>>> filtering >>>>> result to be another model instead of group. But, I did not >>>>> understand exactly what the use case is. Could you elaborate some >>>>> more? >>>>> >>>>> Doru >>>>> >>>>> On Nov 30, 2007, at 2:27 PM, stephane ducasse wrote: >>>>> >>>>>> Hi doru >>>>>> >>>>>> is there a way to convert a model into a group? >>>>>> >>>>>> Stef >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev(a)iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> www.tudorgirba.com/blog >>>>> >>>>> "Yesterday is a fact. >>>>> Tomorrow is a possibility. >>>>> Today is a challenge." >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev(a)iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> www.tudorgirba.com/blog >>> >>> "Problem solving efficiency grows with the abstractness level of >>> problem understanding." >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > -- > www.tudorgirba.com > www.tudorgirba.com/blog > > "One cannot do more than one can do." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- www.tudorgirba.com www.tudorgirba.com/blog "In a world where everything is moving ever faster, one might have better chances to win by moving slower." _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev