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

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

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