why do we have subclassHierarchy that in fact return subclasses?

List overview All Threads
Download

newer

older

Roassal: is there an example how...

how we solve the problem of the...

Stéphane Ducasse

7 Dec 2013 7 Dec '13

8:34 p.m.

Show replies by thread

Tudor Girba

7 Dec 7 Dec

9:26 p.m.

New subject: why do we have subclassHierarchy that in fact return subclasses?

This API is there since about a decade. In Smalltalk the selector would have been allSubclasses. However, in Moose, we typically use all for contained elements. This is why it's not called allSubclasses. Another possibility would be to call it deepSubclasses. But, of course, everything is subject to change. Cheers, Doru On Sat, Dec 7, 2013 at 8:34 PM, Stéphane Ducasse <stephane.ducasse(a)inria.fr>wrote;wrote:

...

subclassHierarchy | subclasses | subclasses := OrderedCollection new. self allSubclassesDo: [:each | subclasses add: each]. ^ subclasses to me it looks like too much thinking and this kind of API sucks. I can understand subclassHierarchyDepth because it is about hierarchy but no subclasses. Stef _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com "Every thing has its own flow"

Stéphane Ducasse

10:48 p.m.

New subject: why do we have subclassHierarchy that in fact return subclasses?

...

This API is there since about a decade.

well. I do not think that this is that long.

...

In Smalltalk the selector would have been allSubclasses. However, in Moose, we typically use all for contained elements.

what do you mean?

...

This is why it's not called allSubclasses. Another possibility would be to call it deepSubclasses. But, of course, everything is subject to change.

I do not understand why you choose something that goes against our cultural reference. to me allSubclasses is simple, intention revealing and it works well. I started to create my own extensions because I do not have the brain cells to remember that sublcassHierarhcy which refers to a "bag" returns the bag elements. Stef

...

Cheers, Doru On Sat, Dec 7, 2013 at 8:34 PM, Stéphane Ducasse <stephane.ducasse(a)inria.fr> wrote: subclassHierarchy | subclasses | subclasses := OrderedCollection new. self allSubclassesDo: [:each | subclasses add: each]. ^ subclasses to me it looks like too much thinking and this kind of API sucks. I can understand subclassHierarchyDepth because it is about hierarchy but no subclasses. Stef _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Alexandre Bergel

8 Dec 8 Dec

12:58 a.m.

New subject: why do we have subclassHierarchy that in fact return subclasses?

I do not understand why it is not called #allSubclasses Returning a group of famixclass seems to be what one would expect no? Alexandre

...

Le 07-12-2013 à 17:26, Tudor Girba <tudor(a)tudorgirba.com> a écrit : This API is there since about a decade. In Smalltalk the selector would have been allSubclasses. However, in Moose, we typically use all for contained elements. This is why it's not called allSubclasses. Another possibility would be to call it deepSubclasses. But, of course, everything is subject to change. Cheers, Doru

On Sat, Dec 7, 2013 at 8:34 PM, Stéphane Ducasse <stephane.ducasse(a)inria.fr> wrote: subclassHierarchy | subclasses | subclasses := OrderedCollection new. self allSubclassesDo: [:each | subclasses add: each]. ^ subclasses to me it looks like too much thinking and this kind of API sucks. I can understand subclassHierarchyDepth because it is about hierarchy but no subclasses. Stef _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com "Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Tudor Girba

9:26 a.m.

New subject: why do we have subclassHierarchy that in fact return subclasses?

I said that in Moose we use all* for things like allClasses in a model, and this is why at the time we did it we chose to call it hierarchy. It might not be the best choice, but this is the background. Please do not create extensions. Moose is not readonly :). Modify and deprecate existing ones. Doru On Sat, Dec 7, 2013 at 10:48 PM, Stéphane Ducasse <stephane.ducasse(a)inria.fr

...

wrote:

> > > This API is there since about a decade. > > > well. I do not think that this is that long. > > In Smalltalk the selector would have been allSubclasses. However, in > Moose, we typically use all for contained elements. > > > what do you mean? > > This is why it's not called allSubclasses. Another possibility would be to > call it deepSubclasses. But, of course, everything is subject to change. > > > I do not understand why you choose something that goes against our > cultural reference. > > to me allSubclasses is simple, intention revealing and it works well. > I started to create my own extensions because I do not have the brain > cells to remember that sublcassHierarhcy which refers to a "bag" returns > the bag elements. > > Stef > > > > Cheers, > Doru > > > On Sat, Dec 7, 2013 at 8:34 PM, Stéphane Ducasse < > stephane.ducasse(a)inria.fr

...

wrote:

> >> subclassHierarchy >> | subclasses | >> subclasses := OrderedCollection new. >> self allSubclassesDo: [:each | subclasses add: each]. >> ^ subclasses >> >> >> to me it looks like too much thinking and this kind of API sucks. >> >> I can understand >> >> subclassHierarchyDepth >> because it is about hierarchy but no subclasses. >> >> Stef >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > _______________________________________________ > 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 "Every thing has its own flow"

Stéphane Ducasse

8:20 p.m.

New subject: why do we have subclassHierarchy that in fact return subclasses?

...

I said that in Moose we use all* for things like allClasses in a model, and this is why at the time we did it we chose to call it hierarchy.

OK I try to understand. all* does not goes against allSubclasses

...

It might not be the best choice, but this is the background. Please do not create extensions. Moose is not readonly :). Modify and deprecate existing ones.

So I will add allSubclasses We can keep

...

> subclassHierarchy

Is there another case like that one? Stef > > Doru > > > On Sat, Dec 7, 2013 at 10:48 PM, Stéphane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > >> This API is there since about a decade. > > well. I do not think that this is that long. > >> In Smalltalk the selector would have been allSubclasses. However, in Moose, we typically use all for contained elements. > > what do you mean? > >> This is why it's not called allSubclasses. Another possibility would be to call it deepSubclasses. But, of course, everything is subject to change. > > I do not understand why you choose something that goes against our cultural reference. > > to me allSubclasses is simple, intention revealing and it works well. > I started to create my own extensions because I do not have the brain cells to remember that sublcassHierarhcy which refers to a "bag" returns > the bag elements. > > Stef > > >> >> Cheers, >> Doru >> >> >> On Sat, Dec 7, 2013 at 8:34 PM, Stéphane Ducasse <stephane.ducasse(a)inria.fr> wrote:

...

> subclassHierarchy

>> | subclasses | >> subclasses := OrderedCollection new. >> self allSubclassesDo: [:each | subclasses add: each]. >> ^ subclasses >> >> >> to me it looks like too much thinking and this kind of API sucks. >> >> I can understand >> >> subclassHierarchyDepth >> because it is about hierarchy but no subclasses. >> >> Stef >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> _______________________________________________ >> 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 > > "Every thing has its own flow" > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Stéphane Ducasse

8:21 p.m.

New subject: why do we have subclassHierarchy that in fact return subclasses?

...

I do not understand why it is not called #allSubclasses Returning a group of famixclass seems to be what one would expect no?

indeed we could also add a group. Is there is a convention to create groups or not?

Tudor Girba

10:01 p.m.

New subject: why do we have subclassHierarchy that in fact return subclasses?

Hi, Yes, there is. Groups are expensive, so for longer computations we want to work with raw collections. Groups are more useful when we get in the UI. You can always pass asMooseGroup to any object when you script. For annotated methods (properties), they should return groups. So, for groups we have methods like: FAMIXType>>methodsGroup <navigation: 'Methods'> ^MooseGroup withAll: self methods withDescription: 'Methods from ' , self mooseName Doru On Sun, Dec 8, 2013 at 8:21 PM, Stéphane Ducasse <stephane.ducasse(a)inria.fr>wrote;wrote:

...

I do not understand why it is not called #allSubclasses Returning a group of famixclass seems to be what one would expect no?

indeed we could also add a group. Is there is a convention to create groups or not? _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com "Every thing has its own flow"

Alexandre Bergel

10:24 p.m.

New subject: why do we have subclassHierarchy that in fact return subclasses?

#withAllSubclasses is also very important. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Dec 8, 2013, at 4:20 PM, Stéphane Ducasse <stephane.ducasse(a)inria.fr> wrote:

...

I said that in Moose we use all* for things like allClasses in a model, and this is why at the time we did it we chose to call it hierarchy.

OK I try to understand. all* does not goes against allSubclasses

It might not be the best choice, but this is the background. Please do not create extensions. Moose is not readonly :). Modify and deprecate existing ones.

So I will add allSubclasses We can keep

> subclassHierarchy

3815

days inactive

3816

days old

moose-dev@list.inf.unibe.ch

Manage subscription

8 comments

3 participants

tags (0)

participants (3)

Alexandre Bergel
Stéphane Ducasse
Tudor Girba