Add computed category "extensions" to show methods in other packages

[ericwinger]

In a style similar to what Pharo does, compute a category named extensions in the browser in the category list.
It should be visually distinct from other categories and show all methods extended in other packages.

[ericwinger]

Now that we have the Package tab again, we can see which methods are in which package. I don't think a computed extensions category is still needed. Thoughts, @dalehenrich ?

The Pharo extension category is displayed for comparison.

[dalehenrich]

We are trying to get away from using categories for packaging info, however, for the Monticello and RowanHybrid package conventions, the tonel file will record a fabricated *<package-name> category and there is no room to store an additional category name, so we can't put these Monticello/RowanHybrid into anynormal category and almost "have to use" a computed category for those methods (similar to what Pharo does ... and for similar reasons)

The Rowan package convention does indeed ignore the category for packaging purposes, so we could continue to get away with defining a category for Rowan convention extension methods and I assume that these methods WOULD NOT show up in the computed category.

Rowan package convention is incompatible with Pharo and Monticello/RowanHybrid will have to be used for cross-platform projects.

My thoughts are that we should discuss this in more detail 😄

[dalehenrich]

Here's a first cut at a description of how we will be manipulating methods and I think that we might still want to have the computed extensions category ... but we have more information to work with ....

Tonel constraints

The method category field on disk must be defined.

RowanHybrid

*PACKAGE-NAME

Monticello

*PACKAGE-NAME

ROWAN

<category-name>, default ‘other’

Jadeite Method Constraints

1. A method must be created in a category and by default it will be created in the package of it’s class. A class may be unpackaged (nil package field).

2. After creation a method may be moved to another package and will become an “extension method”

   RowanHybrid/Monticello

   The category of the method will become *PACKAGE-NAME and it will be displayed in the computed Extensions category

   Rowan

   The category of the method will remain unchanged, but the method will be displayed in its named category and the computed Extensions category

3. A method may be moved from an extension packaged to the package of its class

   RowanHybrid/Monticello

   The category will become the default category (‘other’) and it will no longer be displayed in the computed Extensions category

   Rowan

   If the original package was Rowan convention, it’s category will remain unchanged and it will no longer be displayed in the computed Extensions category.

   if the original package was RowanHybrid or Monticello, it’s category will become ‘other’ and it will no longer be displayed in the computed extensions category.

4. A class may be moved to a different package and the method categories will have to be adjusted.

   Rowan to RowanHybrid/Monticello

   All of the extension methods that were in the target package will no longer be extension methods and will retain their original category.

   All of the extension methods that remain extension methods will retain their category/extension method status.

   All of the non-extension methods that were in the original package will be moved to the target package and will retain their original category.

   RowanHybrid/Monticello to Rowan

   All of the extension methods that were in the target package will no longer be extension methods and will be moved to the default category (‘other’).

   All of the extension methods that remain extension methods will retain their category/extension method status.

All of the non-extension methods that were in the original package will be moved to the target package and will retain their original category.

[dalehenrich]

Will need to describe what happens when an unpackaged class with extension methods is moved to Rowan and RowanHybrid/Monticello packages

[dalehenrich]

It seems that the point of the computed extension category is not about displaying package information, but about how to deal with extension methods when the category tab is enabled, since some of the methods will not have a category defined and for those methods (in RowanHybrid and Monticello packages) we do not want to display the tonel category because we do not want users to think they can create or move a method to those categories ... remember we got here because we're trying to get out of the business of using the category for packaging information .. so I think it is "cleaner" to hide the tonel categories in the category tab than to disallow method creation or moves into the SPECIAL tonel categories... but cleaner or not is open to discussion ...

With Rowan packages the tonel category is not part of the convention so we could get away with not displaying Rowan package extensions in the computed category, but if we have an 'extensions' category that does not show all extension methods I think that is odd... but this is a debatable point as well

[dalehenrich]

A "final" note ... we need to disallow the creation of categories that look like they could be interpreted as a RowanHybrid/Monticello tonel category ...

[ericwinger]

After discussions, having a simple computed extensions category is a helpful tool. I'll add that and we can make it more feature rich in the future if desired.

• The computed 'extensions' name should be purple

[ericwinger]

Computed extensions category seems to be mostly working.

category is purple
category can't be deleted
category only shows method extensions (purple) in the selected class
'extensions' category can still be created.

796084a