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
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@inria.frwrote:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@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@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@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@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
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@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@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@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@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
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
#withAllSubclasses is also very important.
Alexandre
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@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@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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?
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@inria.frwrote:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Alexandre Bergel -
Stéphane Ducasse -
Tudor Girba