Hi Lukas,

This sounds really useful. 

Since these changes are not backward compatible I'll try to provide
automatic refactorings for most parts. Moving existing code to the new
codebase will certainly cause some problems, but in the long run I
believe this to be a much better approach than the current one. If
people have any feedback, concerns or other changes that would be
important in the same run I am happy to hear them.

I am using similar tricks to the ones Yanni indicated above to build instance specific instances - so it looks like your proposal would simplify that code considerably. I've also been bitten by the name clash with #description.

One specific annoyance I have is with class extension description methods that are installed by addons that I can't disable (I currently delete the methods). Specifically:

PRCase>>descriptionDocumentTagCloud: aDescription
^ aDescription beTagCloud

PRStructure>>descriptionNameTagCloud: aDescription
^ aDescription beTagCloud


I use the TagCloud addon, but don't want the structure name to be included and instead of document I use plain text (arguably the plain text change might be more widely applicable, but probably the first is more specific to my use cases)

Perhaps it's overcomplicating to be able to disable class extension descriptions - without making the code incomprehensible.

---

The other issue is with Magritte description caching and Gemstone. After I change a description in Gemstone I have to remember to flush the description cache. This seems to be due to a combination of Gemstone's classHistory and lack of support for weak collections(?). Is this on your radar?

----

I imagine your proposed changes will require some effort to rework Pier - as it uses Magritte extensively - I guess we can all pitch in to try to make it happen smoothly - perhaps we could organise a Camp Magritte/Pier??

----

Nick