3 Dec
2007
3 Dec
'07
12:34 p.m.
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:
--
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 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:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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