[Seaside-dev] [ANN] Port of Pier to VW

[Niall Ross]

A first port of the Pier CMS framework from Squeak to VW is in the 
Cincom open repository:  It prereqs Porting-Namespaces (any version 
should be OK) and requires compatible versions of Magritte and 
MagritteForVisualWorks (anything with '...CS12.NFR...' in the version 
name should be OK).

This version ports
    Pier-Model-lr.150.mcz      24 April 2007 9:28:18 pm
    Pier-Seaside-lr.147.mcz      28 March 2007 10:04:08
    Pier-Tests-lr.69.mcz      24 April 2007 9:25:44
    Pier-Security-lr.80.mcz      24 April 2007 10:27:20
I will now get the latest Squeak version and port its changes likewise.

The parent version holdes a raw port of the unmodified code (with 
'broken' blessing level as it will not work in VW, nor load very well).  
The child version holds the corresponding VW-ized code.

See the blessing comments for port details.  I mention some points here 
to invite discussion.

Handling duplicate class names
=====================
Where Squeak and VW have duplicate class names (e.g. Date, Color or 
Time) that Seaside needs, the Seaside port creates subclasses of the 
preferred class in the target namespace, i.e. in Seaside, to get the 
correct resolution.  With Magritte and Pier both importing Seaside, and 
other namespaces being added, this seemed to demand a plethora of 
same-name subclasses, one for each case in each new Squeak-importing 
namespace, so I am trying a new approach which has worked OK for me in 
other cases.

I have made Magritte and Pier into FirstFoundNameSpaces (see 
Porting-Namespaces package) and reordered their imports so that the 
desired resolution of any clash is the one first found.  This avoids 
both sides of the choice of either creating spurious subclasses or make 
spurious simpleName-to-fullName changes in ported code.  (With some 
minor additions, not yet published, it also makes it a lot easier to 
load untransformed Squeak - or other single-namespace dialect - code 
into VW and get correct resolution of all superclass names in class 
definitions and of all class names in extension methods.)  The point is 
that code from a single namespace dialect necessarily had the same 
resolution of each name, so a target VW namespace that offers each 
preferred resolution as the first-found one in all cases is always 
possible.  (DefaultPackageNamespaces must be used in *-Extensions 
packages to get correct resolutions in extension methods.)

Comments welcome re whether this is useful
    - while porting
    - in general  .

Set and Dictionary equality
==================
(This must surely have been raised before, but my attempts to find 
relevant past posts in any appropriate list have drawn a blank.)  Some 
Pier test assertions rely on Squeak's implementation of equality for 
Dictionaries and Sets, which also checks if their contents are equal.  
In VW, Dictionary and Set equality do not check equality of contents.  
Someone porting such code cannot provide the Squeak implementations as 
extensions since the base VW image does not like this, producing 'memory 
emergency' on various operations:  I deduce that some VW Dictionaries 
and Sets have contents whose equality tests create circularities with 
this.  I've therefore added Set>>=@ and Dictionary>>=@ to provide the 
Squeak implementations, as the easiest way to edit the failing 
assertions.  I chose =@ thinking the @ would suggest 'is equal at (its 
various contents)'.  I made it binary only because that makes it a 
little less work to rewrite the tests than with a keyword method.

Comments welcome, both in general and re my choice of method name.

Trivial common coding style remarks
========================
Most points are already known from Seaside and other ports.  One that 
did not arise in Seaside or Magritte AFAIK is that sort/sort: returns 
the sorter, not the sorted collection, in VW so needs code like
    ... := ... sort ...
changed to
    ... := ... sort ... ; yourself
Writing sort-in-place code this way in Squeak would make for commonality 
when porting is expected.

Since VW's class-side #raiseSignal is already common to both it and 
Squeak (or already ported to Squeak), I've used it to replace the 
#signal method (that it calls in Squeak) in Pier code, rather than add 
#signal to VW.

          Yours faithfully
             Niall Ross