This is an old revision of the document!


Package Structure

A top bundle ({PDF Development}, {Fonts Development} and {Values Development}) contains the runtime code first. Runtime code shall not depend on any other code in the bundle and shall be the only code needed for a runtime application.

The runtime code would be the core part to be ported to other Smalltalk environments.

Every module shall have tests in a separate pundle which are to be loaded after the runtime.

There can be platform dependend pundles for UI's and development environment extensions. This shall be loaded after the runtime.

{..} is Bundle, [..] is Package, bold is runtime

  • {PDF Development}
    • {PDF}
      • [PDF Namespace]
      • [PDF basics]
      • [PDF Basic Objects]
      • [PDF Complex Objects]
      • [PDF Filter]
      • [PDF Streams]
      • [PDF Data Structures]
      • [PDF Graphics Operations]
      • [PDF Graphics]
      • [PDF Colour]
      • [PDF Shading]
      • [PDF XObjects]
      • [PDF Images]
      • [PDF Fonts]
      • [PDF Parsing]
      • [PDF Files]
      • [PDF Document]
      • [PDF Rendering]
    • {PDF Testing}
      • [PDF test resources]
      • [PDF tests]
    • {PDF UI}
      • [PDF UI Support]
      • [PDF Explorer]
    • [PDF Development]

PDF depends on Fonts for text graphics.

  • {Fonts Development}
    • {Fonts}
      • [Fonts Basics]
      • [Type1]
      • [CompactFontFormat]
      • [OpenType]
      • [Fonts Runtime]
    • {Fonts Testing}
      • [Fonts test resources]
      • [Fonts tests]
    • [Fonts for Windows]
    • {Fonts UI}
      • [Fonts UI Support]
      • [Fonts UI]
    • [Fonts Development]

PDF and Fonts depend on Values:

  • {Values Development}
    • [Values]
    • [Values Development]
    • [Values Testing]

Submitted by bobcalco on Fri, 2012-02-03 11:04.

Could you please describe in a bit more detail how the Values package is designed and what exactly it's supposed to facilitate. Is it specifically for pdf4smalltalk or does it have a larger remit? I have looked at it, but I find it a bit confusing, as I am beginning to get my head around the current implementation of pdf4smalltalk.

My desire is to begin to port it to Dolphin, both in order to learn it inside-out, and to learn how to use it in VW.

Submitted by ChristianHaider on Fri, 2012-02-03 13:34.

Cool!

The Values package is my base library for almost everything I do. It provides Values (as opposed to Objects) which are simple, immutable objects. Values can only be created but never modified. This allows for a functional programming style and simplyfies systems, since much less state has to be maintained. Especially I like to see all structure and details (of complex values) at a glance and the ease of creating test values.

I wrote a (scientific) dry paper about it and presented it at ESUG 2009 in Brest. I think that nobody understood it… :-). One can buy the paper from the ACM. The slides of the talk are here. On request, I could send you a draft of the paper on which the ACM does not have the copyright :-).

For porting, I would strongly suggest to start with (parts of) the Values code. But this should not be too much of a problem, since you do not need everything. The “Values” package contains all essential runtime code: Value class, the value printer and compatibility methods for system classes to be used as values. That is sufficient to implement the existing Value subclasses used by Fonts and PDF. The “Values Development” package adds the ability to generate methods for your own Value subclasses. This would not be strictly necessary for porting PDF or Fonts.

For understanding Values in the code, you just need to look at the class method #localSpecification where all attributes/instvars of a Value class are defined.

Submitted by bobcalco on Fri, 2012-02-03 13:53.

I see now what you're up to with that. Do send me whatever you can by way of the paper you wrote, though, I'm very interested in it.

I am quite fond of functional programming, and have done Erlang, Haskell, F# and Scala work, so I do get the concept of immutable values.

What I miss from that world more than anything are the various kinds of list and other 'comprehensions' and I'd love to see Smalltalk acquire some of that syntax. Also, pattern matching is quite cool, though it seems to me slightly less relevant in Smalltalk.

  • packagestructure.1456743011.txt.gz
  • Last modified: 2016/02/29 11:50
  • by christian