May I suggest
that you remove #asString from UndefinedObject and
replace all #asString
sends by #displayString in Magritte. Once you have an inventory of
all these replacements,
you will just need to apply them to the Squeak package and do
another port. I found about
15 occurences of #asString sends in Magritte. Of course this would
have to be
negotiated with Lukas. That's why I copied him.
I seem to be haunted by #asString in every Smalltalk dialect I come
across. In my real life (a VisualAge/GemStone/ObjectStudio shop),
we've adopted #displayString as well. While I'm willing to make
that change, I'd certainly prefer it if we could prevail upon Lukas
to do it, if only to avoid coordination issues.
The problem here is that this will turn the Magritte-Core package
dependent on the Seaside package, because it already defines
#displayString. Otherwise I don't see a problem to adopt this in the
Squeak Code.
2) Among
others, the Seaside-VW bundle includes bundle Squeak.
This bundle is intended
to group all extensions that are needed by VisualWorks to look
like Squeak. It is used by
Seaside but can be used by any project that is ported from Squeak.
I could see that your
Magritte port contains a lot of extensions that would be better
placed in the Squeak bundle.
May I propose the following. I can create a version of the Squeak
and Seaside bundles in
the public store with as many as poissible of the Squeak
extensions needed by Magritte.
When it is ready, I let you know, then you will be able to remove
the extensions from your
Magritte port.
I'm quite happy to go this route. I was getting a little dismayed
at the number of Squeak-isms that I had to implement for the port,
and any work done getting them out of the Magritte package will
help other porting efforts.
If you have any idea to reduce these I am happy to accept patches.
A question for Lukas: I came across the use of
SystemChangeNotifier in Magritte. I ended up either removing or no-
oping operations related to it. Is there something I'm losing as a
result? I couldn't find any uses outside of Magritte that didn't
appear to be related to the development environment itself.
There are two uses of SystemChangeNotifier, they should be probably
moved to the MACompatiblity class.
1. MAAutoSelectorAccessorTest: this one is only needed to prevent
from marking the test-package dirty as this tests adds/removes i-vars/
accessors.
2. MADescriptionBuilder: this one makes sure that the description
cache is flushed whenever a description method is changed/added/removed.
The first one isn't critical, as this is only a tweak to make the
test run clean. The second one is more critical, without it you need
to flush the description cache manually by executing
MADescriptionBuilder default flush
There were some concerns in the beginning that rebuilding those
descriptions over and over again is very costly, therefor I added the
caching. I don't know if this is still relevant. Probably it hurts
more than it helps, but we have to check.
Lukas, I've uncovered a small bug in
MAReportComponent. While the
#renderContentOn: method calls #labelId, that method is not
implemented in the class hierarchy. I'm not sure if the
implementation from MAElementComponent should be moved up, or if
something else was intended for the report hierarchy. For
reference, this is in package Magritte-Seaside-pmm.206.
I think this change was introduced by the latest change of Philippe,
maybe he can have a look?
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch