Tobias,
Presumably SystemOrganizer is consistent with the Squeak/Pharo API so the differences you are seeing are because Squeak/Pharo and GemStone treat categories differently.
If you are trying to write portable code between Squeak/Pharo and GemStone, then you should probably just use SystemOrganizer ...
If you find that you need to use both ClassOrganizer and SystemOrganizer, then I would need a bit more information about what you are doing to help figure out the best approach ...
Dale
----- Original Message -----
| From: "Tobias Pape" <
[hidden email]>
| To: "GemStone Seaside beta discussion" <
[hidden email]>
| Sent: Thursday, May 23, 2013 3:51:03 AM
| Subject: [GS/SS Beta] SystemOrganizer and ClassOrganizer do not agree
|
| Hello GemStoners
|
| I am currently trying to cross-grade Monticello
| for making my SqueakSource work with Pre/Post-scripts
| and upon running tests, I found the following Precious.
|
| Monticello wants to deal with Class-Categories
| (creation, renaming), and it bit me that
| SystemOrganizer and ClassOrganizer do not agree:
|
| SystemOrganizer mostly operates on its
| categoryDict and makes sure that every key handed to
| it is made a symbol (#classify:under:, #listAtCategoryNamed:,
| and especially #renameCategory:toBe:).
| The categoryDict itself is initialized via
| ClassOrganizer's categories, which, however
| is a StringKeyValueDictionary (see #rebuildCategories
|
| "gemstone64, changed categories from a SymbolDictionary
| to a StringKeyValueDictionary to avoid unnecessary symbol
| creation"
|
| ).
|
| Since Stings and Symbols _explicitly_ do not compare with #=
| (String>>#=
| "Returns true if corresponding Characters in the receiver and
| argument are equal
| and aCharCollection is comparable with the receiver, and
| aCharCollection is
| not a kind of Symbol. Returns false otherwise. ...")
| #renameCategory:toBe: must inherently fail...
|
| So, how should I proceed? Patch SystemOrganizer to reflect
| ClassOrganizer
| or add some other methods?
|
| Best
| -Tobias
Locked
