22 Dec
2006
22 Dec
'06
9:35 a.m.
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.
I guess the question that would need answering is, how many users
would be affected by having load the Seaside package first? In the
case of the VW port, I pre-req Seaside anyway. What how many
Squeak users are _not_ using Seaside with Magritte? I think both
of those users could live with having to load the Seaside code as
well. :{) There are two
uses of SystemChangeNotifier, they should be
probably moved to the MACompatiblity class.
Ah, yes, the "Incompatibility" class, as I call it. :{) That, and
the MADistribution class came over to VW with just about nothing
working. 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.
Uh oh, the evil spectre of premature optimization rears its ugly head! For development purposes, I can live with manually
flushing the
cache as needed.
It was like this in beginning of Magritte. It is just more convenient
not to have to worry about invalid caches. Maybe in you case you want
to disable it altogether, have a look at MANamedBuilder and replace
its references (should be only one) with your own implementation that
does not cache.
For a runtime environment, my personal preference is
to use
packaged images anyway, so I find it hard to worry too much about
the impact of code changes. If we document a need to flush the
cache, I think that should be sufficient, unless someone more into
the internals of VW browsers has a better idea.
Yeah, for deployment this doesn't matter anymore. Descriptions you
bild programmatically (or you end-users are building) are not cached
anymore.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch