26 Jan
2012
26 Jan
'12
12:28 p.m.
Hi Davorin,
Well, once the dust settles, I guess migrating old pier instances
people are using could raise all kind of strange
issues. (not that I
am ungratefull for progress :)
That's a great point. One of the issues with Pier is how to upgrade to a
new version - I found this particularly challenging on Gemstone as I ended
up with multiple version of the same class (#classHistory size ~= 1) which
caused strange bugs with class equality checks in the code-base.
One idea I came up with is to build an exporter which generates Pier kernel
creation code based on the data currently in Pier - it's a lazy design as I
only have to write an exporter not an importer. I've used it successfully
on a few smaller projects but have yet to try it on more substantial
projects.
The code is available in http://source.lukas-renggli.ch/pier2addons -
package Pier-Exporter-Code.
To use it:
PRKernelCodeExporter exportKernel: (PRKernel instances detect: [: each |
each name = 'pier']).
The exporter generates PierKernelCreator
and the kernel can be recreated with:
PierKernelCreator new createKernel
A Pier upgrade procedure could then be:
1) load PRKernelCodeExporter
2) export your kernel to code
3) try to regenerate your kernel
4) if 3 is successful then export the created code; PierKernelCreator
5) load PierKernelCreator and any of your custom Pier code into a Pier
image with pragma support
6) Ensure that all add ons you use have been ported, including any of your
own code using the porting guide outlined at the start of this thread.
I will add PRKernelCodeExporter class>>#exportMigratedKernel: which will
generate #prototypeInstance initialisation for PRComponents, but first I'd
like feedback if people think this approach is worth pursuing in theory and
if so, in practice does the PRKernelCodeExporter work on your existing
kernels?
Nick