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@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."
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@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@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
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:
- empty collection, because there is no class inside the group
- total classes from P1 and P2
- 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:
- a collection with C2
- a collection with C1 and C2
- 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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
- empty collection, because there is no class inside the group
- total classes from P1 and P2
- 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:
- a collection with C2
- a collection with C1 and C2
- 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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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."
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:
- empty collection, because there is no class inside the group
- total classes from P1 and P2
- 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:
- a collection with C2
- a collection with C1 and C2
- 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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@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."
thanks this week my priority is to write a project description and the next one is moose.
Stef
On 4 déc. 07, at 01:41, Tudor Girba wrote:
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:
- empty collection, because there is no class inside the group
- total classes from P1 and P2
- 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:
- a collection with C2
- a collection with C1 and C2
- 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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 30 nov. 07, at 17:24, 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.
Yes :) This is nice to get understood :)
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.
Indeed
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.
Ok may be doru should do that/. I will read the group implementation this week.
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
A scenario:
I have a model, I apply a filter : #allClasses I obtain a group now I cannot combine such filters because GroupOfClasses and Model are not polymorphic so I'm stuck.
Stef
On 30 nov. 07, 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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Adrian Kuhn -
stephane ducasse -
Stéphane Ducasse -
Tudor Girba