This is an old revision of the document!
Submitted by ChristianHaider on Fri, 2011-09-02 09:19
It's just too confusing…
Things you need in daily life like Array should not have the same name in the PDF namespace. Generally, I want to have a close correlation between the names of the domain and the Smalltalk class names implementing them. This worked well with PDF but not perfect. F.ex. the class EncryptedString implements the concept of an encrypted string, but the name EncryptedString does not appear in the specification.
Therefore, I should take the naming a bit more relaxed. I start with /Array to be renamed to /PDFArray to avoid confusion with Smalltalk Array which is used in code a lot. Next candidates may be /String and /Dictionary.
Also, naming key classes uniquely simplyfies ports to dialects without namespaces.