17 Nov
2010
17 Nov
'10
7 p.m.
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