[Moose-dev] Re: Is there a way to convert a model into a group

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