Fwd: [ANN] Port of Pier to VW

---------- Forwarded message ----------
From: Niall Ross <[hidden email]>
Date: Sep 24, 2007 4:56 PM
Subject: [ANN] Port of Pier to VW
To: [hidden email]
Cc: [hidden email], [hidden email],
[hidden email], [hidden email]


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

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki