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

[Niall Ross]

Reasonably up-to-date (less than a week old) ports of Magritte and Pier
from Squeak to VW are now in the Cincom OR.

> 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
>
>
>