On loading WxSqueak into a fresh 3.7

[Steven Swerling]

Rob Gayvert wrote:

> Is there a better way of handling all of the constants? Would using a 
> SharedPool help in any way?

That occurred to me. I didn't try it, though. My hunch was that it might 
seem a bit strange. That's because shared pools resolve the problem by 
making one class variable for *every* contant in the dictionary (browse 
ZipConstants to see an example). Not sure what the impact would be at 
runtime, pro or con. But during development, every time you clicked on a 
class in the browser, it would likely take awhile to display the class 
definition in the code pane. Not a deal-breaker, but it gave me pause.

>> Perhaps some interim steps are in order (but imminently deferrable). 
>> Try to make 4 separate Wx monticello packages:
>> - A package for all the base system extentions, called, say, 
>> *wxextentions. Easy.
> 
> And most of this will probably go away with ToolBuilder.

Yeah.

>> - A package for the plugin generation. This stuff has a dependency on 
>> VMMaker, itself a rather large package, so it might be nice to 
>> separate out from Wx proper. Probably pretty easy.
>
> Yes, my intention was to make the code generation classes disposable. I 
> need to see if there are any lingering dependencies.

Just that the plugin is subclassed from SmartSyntaxPlugin, which is part 
of VMMaker, itself a pretty hefty chunk. Nothing wrong with that (and 
probably a lot is right). It's just that if the Wx classes that support 
generation are in a separate package, it would make that much easier to 
build a deployment image without them.

>> - A WxBootstrap package that just contains those few classes needed to 
>> get filed in so that all the constants can be initialized. It's 
>> necessary to initialize all the constants before all the subclasses 
>> that access those constants get filed in. This is complicated by the 
>> fact that some of the WxConstants are objects from the Wx sub 
>> hierarchy (like a WxColour for wxBlack). Very hard.
> 
> 
> Do things like wxBlack really need to be initialized, or just be present 
> in the pool dictionary? My current change set simply sets the ones with 
> object values to nil (in fact, all of the int values are bogus, and may 
> vary by platform). All of the constants (ints and objects) get loaded 
> from the plugin at startup time (WxBase initialize).

This is the money question. When you file in all the subclasses of 
WxObject (and thus WxBase), a lot of the methods have constants from the 
WxConstants dictionary. If WxConstants is nil at file-in, the constant 
values in all the code of the subclasses is set to nil. Not sure why 
this worked for me when I filed the changeset into my QuiteSmall image. 
Either there is a difference between monticello and changesets in this 
regard, or I made some mistake.

The ambitious thing to do would be to rewrite the initialization code so 
that a full WxConstants dictionary and the other core constants dicts 
are built *before* any of the classes that rely on them are filed in. 
That's why I proposed a WxBootstrap package, a core set of classes 
(maybe just WxLib and WxBase), with a hook to build all the core 
constant dictionaries. After that is done, you can safely load in the 
rest of the code.

This is all doable, it won't be a killer. But it's hard enough that 
perhaps it should be deferred for now, just make people start with a 
base image that has had all the constants initialized "by hand". The 
WxSqueak classes are not tangled up in the way that, say, EToys is. So 
drawing lines between the various pieces of Wx can be done later.

For Wx, the problem of building from a base squeak image mostly boils 
down to getting all the constants properly initialized before loading 
the code that uses those constants.