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

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.

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.

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.

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.

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