Last update January 24, 2008

Standard Library /
Draft Helmut



This is a draft for a "domain oriented" library (module) design meant as an alternative to a classical "dp oriented" (Java-like) design. Many of the modules listed below are not suggestions for the first release of the library. The green ones seem essential - either they are already available or they should be implemented first. The orange ones might be good to create interest for special target groups. The others (white) are meant as as examples to sketch the growth path and the overall design philosophy. The red one are not meant seriously at the moment, they just show the logic. The design is targeted at bridging the gap to typical applications (not so much as an abstract toolset). See the rationale below the list for further thoughts about the design.

  • dlib
  • dlib.application.args
  • dlib.application.configuration
  • dlib.application.environment
  • dlib.application.errorhandling
  • dlib.application.testing (framework built on unittest feature)
  • dlib.application.thread
  • dlib.application.translation (internationalisation)
  • dlib.database
  • dlib.database.table
  • dlib.database.query
  • dlib.database.report
  • dlib.database.report.print
  • dlib.game.board
  • dlib.game.board.images
  • dlib.game.card
  • dlib.game.card.images
  • dlib.game.logic
  • dlib.internet.cgi
  • dlib.internet.ftp
  • dlib.internet.html
  • dlib.internet.mail
  • dlib.internet.http
  • dlib.io
  • dlib.io.standard
  • dlib.io.file
  • dlib.io.file.directory
  • dlib.io.file.path
  • dlib.io.file.raw
  • dlib.io.file.mapped
  • dlib.io.file.stream
  • dlib.io.file.random
  • dlib.io.print
  • dlib.io.print.document
  • dlib.io.scan
  • dlib.io.mouse
  • dlib.io.gui
  • dlib.io.gui.control
  • dlib.io.gui.form
  • dlib.io.gui.menu
  • dlib.io.gui.spreadsheet
  • dlib.io.gui.chart
  • dlib.io.gui.window
  • dlib.io.console
  • dlib.io.video
  • dlib.io.sound
  • dlib.language.d.parse
  • dlib.language.d.build
  • dlib.language.d.reflect
  • dlib.language.c.library
  • dlib.language.c.preprocess
  • dlib.language.natural.English
  • dlib.language.natural.English.dictionary
  • dlib.language.natural.English.grammar
  • dlib.language.python.library
  • dlib.language.perl.library
  • dlib.language.prolog (logical resolution)
  • dlib.library.xml
  • dlib.library.sql
  • dlib.math
  • dlib.math.constant
  • dlib.math.equations
  • dlib.math.formula (evaluation)
  • dlib.math.function
  • dlib.math.random
  • dlib.math.statistic
  • dlib.math.matrix
  • dlib.tool.find
  • dlib.tool.grep
  • dlib.tool.yacc
  • dlib.type.primitive
  • dlib.type.primitive.complex
  • dlib.type.array (utilities for existing type)
  • dlib.type.char
  • dlib.type.color
  • dlib.type.date
  • dlib.type.document
  • dlib.type.document.file.rtf
  • dlib.type.document.page
  • dlib.type.document.preview
  • dlib.type.document.print
  • dlib.type.font
  • dlib.type.hash (utilities for existing type)
  • dlib.type.image
  • dlib.type.image.file.gif
  • dlib.type.image.file.jpg
  • dlib.type.image.file.png
  • dlib.type.image.file.tif
  • dlib.type.image.processing
  • dlib.type.list
  • dlib.type.net
  • dlib.type.object
  • dlib.type.point
  • dlib.type.rect
  • dlib.type.regex
  • dlib.type.stream
  • dlib.type.string
  • dlib.type.tree
  • dlib.type.unicode
  • dlib.science.geometry
  • dlib.science.geometry.d2
  • dlib.science.geometry.d3
  • dlib.science.physics
  • dlib.science.physics.const
  • dlib.science.physics.unit
  • dlib.science.physics.mechanics
  • dlib.system.linux
  • dlib.system.portable
  • dlib.system.windows
  • dlib.system.mac

Rationale

The fundamental idea in the library design should be "How can we create the simplest possible interface for the application programmer".

The library and its modules should be implemented together with applications, tools and tutorial examples that use it. In general nothing should be designed without a need. Availability of a feature in Perl and Python libraries should be seen as a proof for such need.

Contrary to Java this design doesn't reflect implementation detail or an object hierarchy. It tries to create an extensible picture of how an application programmer models the world or structures his application. It's top down, not bottom up.

The green library should be doable in 2004. At this time the library should be competitive for tool development and applications using interfaces to external libraries (e. g. wxWindows or DIG for GUI development). It should also be possible to do performing CGI programming, that has been lost by C to the script languages.

The white library including most of the modules above may take 3-4 years to implement step by step in frequent releases. This depends on the resources available (and on the selection of this draft of course). At this time it should be possible to do Windows/Linux-portable database/gui/printing multiuser applications out of the box rivaling Delphi/Kylix and OFFICE/ACCESS as an office application programming environment. That's the long-term vision.

Implementation

Contrary to Java no big object hierarchy is planned. Most important features have procedural interfaces. Many object exist on their own, without much inheritance around them (e. g. RandomFile, String or Image). Functionalities will often be callable in three different ways: as an overloaded function, as a //CanonicalFunction and as an object method (when it makes sense). One can rely on the compiler to inline the necessary translations so that no overhead is produced.

Philosophy

For a lot of programming tasks "implementation objects" are just intermediate steps, that are more or less in the way to do the necessary transformations. Only a small number of objects is really needed. Some examples:

  • on the way "file => string" no object is necessary - this may be done in one command (we don't want do create a file implementation object and think about how to operate it)
  • when doing "scanner => image => printer" and "scanner => image => file" and "file => image => printer" we have always two transformation (function calls) and need only one intermediate object "Image" for our work (we don't need to make all possible image formats and image types to be complex object hierarchies we have to know about to do this job)
  • ...
Object orientation can be seen on a higher level than in OO programming, it then becomes "object oriented thinking". Even objects that are not implemented as objects are seen and treated as objects. FileDelete(filename) uses a symbolic object reference to deal with a real world object. The "implementation objects" have no right to live on their own, they should only exist when they offer an advantage in modeling the real world.


FrontPage | News | TestPage | MessageBoard | Search | Contributors | Folders | Index | Help | Preferences | Edit

Edit text of this page (date of last change: January 24, 2008 21:58 (diff))