[V3] move away from using method category as key to determining package membership

[dalehenrich]

With Rowan 3, Jadeite itself is aware of packages and supports moving individual methods from one package to another without relying on the Rowan 2 method of moving the method into a method category associated with a package by using the name of the package prefixed with an '*".

This gives us the freedom to eliminate the need to align method categories and package names (see #875 and #908).

The current browser support and method compilation API in Rowan will significantly refactored. Support for adding new methods to a class will likely include variations on these methods:

• rwCompileMethod:
• rwCompileMethod:category:
• rwCompileMethod:packageName:
• rwCompileMethod:package:
  While the existing move method messages will survive (likely with a different implementation):
• rwMoveMethod:toPackage:
• rwMoveMethod:toCategory:

It is very likely that the Rowan API in this area will be greatly simplified. I anticipate that the class RwPrjBrowserToolV2 will be completely eliminated.

Changes to the audit code will also need to made.

The Rowan upgrade code will also have to be updated, since it is very likely that the upgrade process from Rowan 2 to Rowan 3 will involve allowing for the proper handling of methods defined in categories starting with a '*'.

In a discussion with @ericwinger, once the necessary changes have been made to Rowan he will change the Jadeite browsers (both Dolphin and Pharo versions) to display extension methods in a synthetic extensions method category (if I recall correctly), while methods that are in the same package as the class will still be associated with a method category. Jadeite already has a packages tab which allows methods to be viewed by package membership and this feature will continue unchanged.

To maintain compatibility with Monticello and RowanHybrid conventions, method categories starting with a '*' will be disallowed, while on disk , the category field will be occupied by the package name with a leading '*'.

The Rowan package convention was invented to allowed extension methods to be intermixed with class methods in the same method categories (i.e,, method categories are completely independent of package membership), we expect that we will continue to support the mixing of methods from different packages in the same method categories, while also showing the synthetic extensions category (I think).

The disk format for Rowan package convention is not compatible with the Monticello packing convention used by Pharo and Squeak. For projects that are expected to be cross platform, the Rowan package convention should not be used ...

[dalehenrich]

We'll need to remove or reimplement the following RwPrjBrowserTool methods:

• RwPrjBrowserTool>>addOrUpdateMethod:inProtocol:forClassNamed:isMeta: - this guy interprets the category and figures out the target package ... which will be unnecessary in the new model
• RwPrjBrowserTool>>addOrUpdateMethodDefinition:forClassNamed:isMeta:inLoadedPackage: - this guy is called by RwPrjBrowserTool>>addOrUpdateMethod:inProtocol:forClassNamed:isMeta: so will no longer be needed

[dalehenrich]

When GemTalk/JadeiteForPharo#68 has been sorted for JfD and JfP, Rowan should throw errors when attempting to use a category with a leading '*' ... especially when an unpackaged class is moved into a package...