(3.2.8) Over-permissive adding *categoryname to Package in UserGlobals, over-restrictive for Package in Globals

[LisaAlmarode]

If a package is in the UserGlobals symbolDictionary, I can add *categoryname categories, regardless of the symbolDictionary of the package matching categoryname. Then I (predictabley) get a walkback if I attempt to add a method to that category: a UserDefinedError occurred (error 2318), reason:halt, The extension class named 'Hamburg1' cannot be found in this symbol dictionary (#'Globals'). Packages that extend a class must be loaded into the symbol dictionary in which the class is installed.

If a package is in the Globals symbolDictionary, I don't seem to be able to add a *categoryname category regardless of the SymbolDictionary of the referenced package (using the add category menu choice). I can get them by dragging a method between packages.

However, I haven't been able to figure out how to add a base method extension.

[ericwinger]

I'm not sure what you get. Is it an error like the example below?

I added *Filein1C category to AbstractBagEnumerator by going to (NONE) project, Globals package, class. Then I tried to create a method and got the attached error. Perhaps the base isn't truly packaged yet?
20220812_rowanServerStackDump.txt

a UserDefinedError occurred (error 2318), reason:halt, Attempt to add a method to an unpackaged class 'AbstractBagEnumerator', while using `hybrid-style` method protocol '*Filein1C'

This might be a good question to raise in Rowan.

[dalehenrich]

Depending upon which project the class is in, this might be the difference between a RowanHybrid/Monticello package convention project which uses the category name for defining which package the method goes into and the Rowan package convention project which does not use the category name for defining which package the method goes into ... technically it is legal to use * category name with Rowan package convention projects as "just a another category" ...

I think that Rowan should be able to do the "right thing", but I'm wondering if we want something closer to the user than a Rowan Warning(?) when a user adds a * category to a class that is using the Rowan package convention? Otherwise the poor user may be left wondering why that method didn't show up as an extension in the "intended package" ...

Let's plan on discussing as a group sometime to brainstorm for alternate approaches ...

[LisaAlmarode]

(1) The error "package not found or not in dictionary" should be made more specific. It's maddening, and giving some detail about which is is would be helpful.

(2) The warning on adding a category is good. But after getting the above error any number of times and finally getting it right... to be then told oh, it doesn't matter just is salt on the wounds. Perhaps the restriction only only creating valid categories should be also conditional on "rowan" packaging (this name is not ideal, very generic - logically everything in rowan must have a packaging type that could be described as rowan)

(3) I cannot for the life of me figure out how to get a base image method extension into my package, which is the actual goal. The * package convention was the old way, but that doesn't work. Dragging not allowed between projects.

[LisaAlmarode]

Note that (3) above is actually issue #274.