Dtone >  Documentation >  Dtone About Dtone > 

Dtone About Dtone


(last update 2001-07-27)

This article descripes how Dtone sees itself. It's a mixture between a description and a mission statement. This thoughts are the baseline which lead to diverse design decissions (and should also for future ones :o)

Dtone is a strong object oriented. The language forces the source code of every dtone project to be structured into entites. All major OO features are either already functional, partially implemented or planned. This includes multpile inheritance, local entities, polymorphism and exceptions.

Dtone is with persuasion a procedural language. This means the source code is a list of instructions telling the computer step-by-step what to do. This allows predictable memory use, and prognostable assembler output. You can estimate how the compiled program will look like by looking at it's source, a characteristic publicly associated with C only.

Runtime speed is crucial to Dtone. We believe there is no real need for an OO language to sacrifice speed beyond as it would have been written in tradional C. Dtone is no interpreter or uses a virtual machine, this field is already well covered by Perl, Python, Java and others. Instead the language is designed with the native processor in mind.

Dtone applications are completly native interfaceable with c libraries, This is at the same time the main virtue of the language, but also it's handicap. The virtue lies in the fact that you can immediatly use a huge set standard functionality out of the box, you only need to write 'hollow' interface entities for the libraries. Another advantage is that one project can under certain conditions consit of mixed sources. The handicap for the language consists that due to this it has to support for (most) c language elements at least a counterpart, this includes in example function pointers. 'native' means you can directly link them together, no need to use something like in example java's JNI.

The Dtone language encorages "context free reading". If in example a user reviews a function, he should be able to understand the doings of the function by looking at it's source code only. Preprocessor macros are in example a violation of this principle. If the reader sees a c macro he must look it up in a header file to understand the function that uses it. Another example are C++ and Pascals reference parameter syntax, at the caller side you'll not be able to determine which paramters can be changed by the called function without looking it up.

Who wants to use yet another language?
First use Dtone for whatever you want! However there is some silhouette in mind. Dtone targets to be used in complexer applications, where strict and easy to use object orientation is a weighty benifit. But you need all the speed, so perfomance lossy highlevel languages (like java) are out of discussion. In example realtime computer games are a possibile field. Other possible example are servers, they are usually complex systems and normally need any perfomance they can get. Dtone is not a language targeted to be the end of all others, it wouldn't suceed eitherway :o) They all have their reasons and personal strenths, and of course this will stay like that. We're trying to offer a mature alternative to C++.