Hi, Class extensions is at the core of the design of Moose. For example, for a class we have as extensions: - numberOfMethods - isJUnit4TestCase - viewBlueprint and viewBlueprintOn: Now, the question is, when to extend an existing class and when not, given that it might lead to a very large amount of methods. To answer this, let's start from the reason for having the extensions in the first place. We want extensions to unify the scripting and the user interface world. For example: - if we are in a MooseFinder, we can see numberOfMethods in the properties pane, because it is meta-described, and we can use it easily in scripting (each numberOfMethods > 10). - The isJUnit4TestCase is not meta-described, but it's meant to be used as a query facility. - viewBlueprint appears in the menu and it is also meant to be used from the inspector. - viewBlueprintOn: this is particularly useful when it is used inside other Mondrian or Glamour scripts So, all in all, you extend when you have: - a meta-described property - a query method (the best kind are unary ones) - a menu entry - a compose-able script Now, when not to extend? Basically, when you do not fall in the above categories :). Here are some examples: - FAMIXClass>>viewMethods: aCollection inBlueprintLayerNamed: aString on: view I can safely provide this as an example, because created it. This is a method that basically only makes sense in the context of the class blueprint. So, it should be bundled together in a separate helper class. - FAMIXPackage>>configurationOfECell This is basically just a helper method that only makes sense in the context of DSM, so it should better be placed there. Cheers, Doru -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her."