11:12 p.m.
Hi
I was wondering if I could get more explanations on the classes of
Moose core:
MooseElement - not sure why it is not merged with MooseEntity
MooseEntity - described as the base class for any entity
MooseAbstractGroup - abstract composite
MooseGroup - my guess, a group of common entities like 'all packages',
'methods from selected class'. Comment says 'Group adds on top the
ability to change the type of a group when we add more items inside',
which is not clear to me
MooseModel - a named group, created only when importing a project into
Moose. I'm not sure why it is a sibling of MooseGroup and not, for
example, a sibling.
Now I am not sure how this model is handled through the moose finder.
Any details to share?
--
Simon
11:26 p.m.
Hi,
To avoid confusion, please specify from now on whether you are talking
about VW or Squeak. From the names used, I guess in this mail you talk
about Squeak :).
MooseElement - not sure why it is not merged with MooseEntity
MooseElement is a kind of an Interface. The difference between
MooseElement and AbstractEntity is that MooseElement has no state.
MooseEntity - described as the base class for any entity
Yep.
MooseAbstractGroup - abstract composite
Yep
MooseGroup - my guess, a group of common entities like 'all
packages', 'methods from selected class'. Comment says 'Group adds
on top the ability to change the type of a group when we add more
items inside', which is not clear to me
In VW there is a GroupTest>>testGroupType that shows the wanted
behavior. Basically, if you add methods in a group and there is a
MethodGroup subcalss of MooseGroup, then you should get an instance of
MethodGroup.
MooseModel - a named group, created only when importing a project
into Moose. I'm not sure why it is a sibling of MooseGroup and not,
for example, a sibling.
a sibling of ? :)
Now I am not sure how this model is handled through the moose
finder. Any details to share?
Moose Finder has not much to do with these, as it should work with any
objects.
Cheers,
Doru
--
www.tudorgirba.com
www.tudorgirba.com/blog
"Every now and then stop and ask yourself if the war you're fighting
is the right one."
11:43 p.m.
On 11 déc. 08, at 23:26, Tudor Girba wrote:
Hi,
To avoid confusion, please specify from now on whether you are
talking about VW or Squeak. From the names used, I guess in this
mail you talk about Squeak :).
Yeah sorry, my main topic is indeed SqMoose.
> MooseElement - not sure why it is not merged with MooseEntity
MooseElement is a kind of an Interface. The difference between
MooseElement and AbstractEntity is that MooseElement has no state.
ok
> MooseEntity - described as the base class for any entity
Yep.
> MooseAbstractGroup - abstract composite
Yep
> MooseGroup - my guess, a group of common entities like 'all
> packages', 'methods from selected class'. Comment says 'Group adds
> on top the ability to change the type of a group when we add more
> items inside', which is not clear to me
In VW there is a GroupTest>>testGroupType that shows the wanted
behavior. Basically, if you add methods in a group and there is a
MethodGroup subcalss of MooseGroup, then you should get an instance
of MethodGroup.
ok, I will delve into VW to get a better picture.
> MooseModel - a named group, created only when importing a project
> into Moose. I'm not sure why it is a sibling of MooseGroup and not,
> for example, a sibling.
a sibling of ? :)
Well, isn't it obvious? :)
Before the typo and the incomplete end of sentence, I meant in fact
MooseModel as a subclass of MooseGroup (for example) - or it could be
that MooseGroup is a subclass of MooseModel. Now it's just a naive
question, I didn't look at the differences between the two.
> Now I am not sure how this model is handled through the moose
> finder. Any details to share?
Moose Finder has not much to do with these, as it should work with
any objects.
ok well, let's keep this discussion for a future (soon to be)
discussion.
Cheers,
Doru
--
www.tudorgirba.com
www.tudorgirba.com/blog
"Every now and then stop and ask yourself if the war you're fighting
is the right one."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon
11:52 p.m.
Hi,
>> MooseModel - a named group, created only when importing a
project
>> into Moose. I'm not sure why it is a sibling of MooseGroup and
>> not, for example, a sibling.
>
> a sibling of ? :)
Well, isn't it obvious? :)
Before the typo and the incomplete end of sentence, I meant in fact
MooseModel as a subclass of MooseGroup (for example) - or it could
be that MooseGroup is a subclass of MooseModel. Now it's just a
naive question, I didn't look at the differences between the two.
MooseGroup adds the ability to morph its type based on the elements
inside. MooseModel has other responsibilities. So they are siblings.
In the same time, they both are subclasses of MooseAbstractGroup
because they share the storage mechanism.
More details about MooseGroup:
- It should be subclassed for every group of entities that is of
interest
- The typed groups can then be home for behavior/properties that are
meta-described and that can be seen in the Finder
- Example of a popular Group is ClassGroup which holds FAMIXClasses. A
behavior of this is viewSystemComplexity to view it in Mondrian.
Furthermore, because in viewSystemComplexity you will get some pragma,
you will be able to construct a menu when you select a ClassGroup in
the Finder.
Cheers,
Doru
--
www.tudorgirba.com
www.tudorgirba.com/blog
"Relationships are of two kinds: those we choose and those that
happen. They both matter."
7:57 a.m.
simon can you add the comments on SqMoose Class, this is also in my
todo.
Stef
On Dec 11, 2008, at 11:43 PM, Simon Denier wrote:
On 11 déc. 08, at 23:26, Tudor Girba wrote:
> Hi,
>
> To avoid confusion, please specify from now on whether you are
> talking about VW or Squeak. From the names used, I guess in this
> mail you talk about Squeak :).
Yeah sorry, my main topic is indeed SqMoose.
>
>
>> MooseElement - not sure why it is not merged with MooseEntity
>
> MooseElement is a kind of an Interface. The difference between
> MooseElement and AbstractEntity is that MooseElement has no state.
ok
>
>> MooseEntity - described as the base class for any entity
>
> Yep.
>
>> MooseAbstractGroup - abstract composite
>
> Yep
>
>> MooseGroup - my guess, a group of common entities like 'all
>> packages', 'methods from selected class'. Comment says 'Group
adds
>> on top the ability to change the type of a group when we add more
>> items inside', which is not clear to me
>
> In VW there is a GroupTest>>testGroupType that shows the wanted
> behavior. Basically, if you add methods in a group and there is a
> MethodGroup subcalss of MooseGroup, then you should get an instance
> of MethodGroup.
ok, I will delve into VW to get a better picture.
>
>
>> MooseModel - a named group, created only when importing a project
>> into Moose. I'm not sure why it is a sibling of MooseGroup and
>> not, for example, a sibling.
>
> a sibling of ? :)
Well, isn't it obvious? :)
Before the typo and the incomplete end of sentence, I meant in fact
MooseModel as a subclass of MooseGroup (for example) - or it could
be that MooseGroup is a subclass of MooseModel. Now it's just a
naive question, I didn't look at the differences between the two.
>
>
>> Now I am not sure how this model is handled through the moose
>> finder. Any details to share?
>
> Moose Finder has not much to do with these, as it should work with
> any objects.
ok well, let's keep this discussion for a future (soon to be)
discussion.
>
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
> www.tudorgirba.com/blog
>
> "Every now and then stop and ask yourself if the war you're
> fighting is the right one."
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
--
Simon
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5218
days inactive
5219
days old
4 comments
3 participants
participants (3)
-
Simon Denier -
Stéphane Ducasse -
Tudor Girba