Fwd: [ANN] Port of Pier to VW

---------- Forwarded message ---------- From: Niall Ross <niallfr(a)btinternet.com> Date: Sep 24, 2007 4:56 PM Subject: [ANN] Port of Pier to VW To: vwnc(a)cs.uiuc.edu Cc: mbany(a)cincom.com, seaside-dev(a)lists.squeakfoundation.org, renggli(a)iam.unibe.ch, nfr(a)bigwig.net 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