Porting PDFtalk to non-namespace Smalltalk dialects

Make the core PDFtalk library available to non-namespace Smalltalk dialects like Squeak, Pharo and VAST. This does not include the UI (the Snooper), which needs to be fully rewritten in another dialect (namespaced or not).

The transformation approach to porting has been successful for Gemstone, which has namespaces. Translating all names in namespaces and their references to prefixed global names has not been done at the time. This is the focus of the current work - see the blog for the current development.

Some information about the project gives more details of the organisation and structure of the project.

The project will first concentrate on Squeak. The next candidate will probably be VA Smalltalk. Ports to other dialects (transformations for other dialects) can be developed in parallel.

Therefore, a separate page exists for each dialect:

• Squeak
• VA Smalltalk
• Gemstone
• Pharo
• (others to come)

1. setup the VisualWorks 8.3 source image with PDFtalk and the tools
2. Port the Values package. This is easy, since no namespaces are involved.
3. Port the PDFtalk packages in order (you can skip PostScript until later)

The workflow for the dialect specific engineer is straight forward:

1. generate the source for the target dialect from VisualWorks with the defined code transformations. Fix problems so that there are no errors or warnings.
2. file in the source into the target dialect. Fix problems so that there are no errors or warnings.
3. file in the tests into the target dialect. Fix problems so that there are no errors or warnings.
4. run the tests
5. fix the problems
   1. by changing code transformations
   2. by implementing missing functionality
   3. DO NOT (well only in the last resort)
      1. change the tests to make them dialect specific
      2. change the original source in VisualWorks
6. Repeat until all tests are passing

Then the port should be finished.

This project is an experiment in somewhat new territory. The goal is to port software from one Smalltalk dialect to another with a declarative approach. This has been done only once for PDFtalk from VW to Gemstone. Now the port is attempted for many non-namespaced Smalltalks at once. The idioms and ways on how to do things are yet to be found and invented.

For this, we need help.

If you have VisualWorks with version 8.3 or later, you can help by adding transformations for specific packages or by improving the transformation machinery.

Port the [Values Tools] and [Values Tools Testing] packages. These packages contain the code for generating new value classes. If you want to create your own Value classes you need this.

Add other source formats (f.ex. tonel) as backend for the transformations (besides the chunk format).

Participate here on the wiki (ask me mail@pdftalk.de for an account if you like to contribute).

Test it, use it, give feedback, ask questions… We are very interested in feedback on the code, documentation, the porting approach, the wiki contents. With your input the code can only improve.

--> Namespaces

(based on input from Marcel Taeumel)

• avoid conflicts with existing system classes or concepts. E.g. rename #Value to #ValueObject for Squeak
• convert namespaces to class-name prefixes. E.g. rename #Page to #PtPage
• follow naming conventions. E.g. rename Dict to #Dictionary
• avoid superfluous subclasses. E.g. rename #ColorValue to #Color for Squeak; install extensions directly in #Color class
• convert occurrences of fully-qualified class names. E.g. the use of “PDFtalk.Fonts.Font” in PDF class » #primeRuntime

• avoid conflicts with existing system categories and Monticello packages. E.g. rename 'Values' to 'VW-Values' or 'ValueObjects' for Squeak
• follow naming conventions such as “no spaces”. E.g. rename 'PDFtalk Graphics Operations' to 'PDFtalk-Graphics Operations' for Squeak; Monticello package could then be just 'PDFtalk' or 'PDFtalk-Graphics' and automatically include all such prefixed class categories

• Should be no issue in PDFtalk because package/bundle path seems to be a superset of the namespaces used. E.g. PDFtalk.Fonts.CFF.Dict is in package [PDFtalk Fonts CompactFontFormat]; so a Squeak class 'PtCFFDictionary' could be in the category 'PDFtalk-Fonts-CompactFontFormat' instead of 'PDFtalk-Fonts-CFF'

• e.g. for bundle {PDFtalk} create class “PtManifest” and use its class comment or any class-side methods as storage
• maybe not only namespaces need to be mapped to class prefixes but also bundle/package (paths) need to be mapped to class names and/or prefixes to create those extra helper classes