[ANN] Port of Pier to VW

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