dool project is started
Status: Alpha
Brought to you by:
antoniorm
Menu
▾
▴
2004/07/28
The dool project, created just a few weeks ago, is hosted on sourceforge.
dool is a D Object Oriented Library to extend phobos where phobos doesnt support the OO paradigm.
Why another lib? Would it ever get popular? Would it split the D community?
These are the first questions that youre thinking about. Valid questions no doubt and all were considered before creating the dool project.
So why? Isnt the D standard runtime library good enough?
The standard D runtime library, phobos, has its problems the first being the development model.
We find phobos development model to be too centralized, and too concern with accepting only final versions of the contribution. The result of this very slow development. Its pathetic how event the small and obvious corrections can take months to make into the library.
The second problem we find with phobos is that it isnt a full OO library. D supports multiple paradigms but for some of us a strictly Object Oriented application is desirable on many project. Phobos as D library doesnt try to use one or other paradigm, it uses what ever the author of each module found to be best for the specific module and we dont always agree with the choice even assuming a multi-paradigm library.
Dool isnt created to change phobos. Dool entries do not have the desire to be promoted to phobos. This is for two reasons. Phobos is not interested on becoming an OO library and dool is not interested in going back to the problems it is trying to avoid. Phobos however is more then welcome to grab modules from dool as its maintainers find fit. Dool is not ashamed of, in many cases being just a repackaging of phobos implementations, in fact one of the goals of dool is to be familiar to phobos user.
Dool will bring a fresh new approach and establish very simple goals:
- dool is a D general runtime library that extends phobos but does not depend on phobos
- dool is a OO library
- dool is open to contributions from anyone
- dool is an evolving project changes are allowed
The acceptance of contributions is based on very simple principles:
- dool is a OO library, every contribution must support exclusively the OO paradigm
- dool will not import phobos modules, instead will re-implement them
- dool will not contain legacy C++ constructs (pointers are the obvious example)
- dool aims for simplicity of use other considerations as speed and size are secondary
- contribution will be accepted if they improve dool
While the first principles are well defined by them self the last one needs some clarification.
This is very simple.
- new functionalities are always accepted (the exceptions are obvious and include malware, legal, and broken submissions), the principle is that something is better then nothing and sometimes its necessary to sparkle the creation of a better version
- the API is not fixed. dool is a work in progress. Bending the API is allowed. If a contribution is to completely replace the existing API for a functionality it will be considered as a different implementation and both the new and the old must be able to coexist.
Will dool ever get popular?
Dool was created from the need to have a strictly OO D runtime library, its our believe that it will be inevitable and so dool is the first attempt on it. Dool hope to attract every body that needs to develop strickly OO applications,. Others will find their own libraries.
So will dool slip the D community and spread and duplicate the efforts to have a decent library?
I doubt that very much. I expect that dool gets the same support en enthusiasm that the community gave to DUI. That will split nothing.
Phobos development model is the one that promotes multiple implementations of the same functionality that is because the implementations never reach the user and so every body will have his own. The example: list dir for linux (we have 4 implementations), another example: stream every body complains about its implementation and for months nothing changed.
So those are the objectives and motivations for the new library dool.
The next version of DUI and leds make use of dool.
On leds the use of dool is completely transparent to the user.
On DUI the developer must be aware of dool. The changes are simple as dool tries to be familiar to the phobos user.
What is on dool?
The first objective of dool was to enable dmd 0.91 to compile DUI and leds and so the first functionalities implemented were the ones that would confuse dmd when imported from phobos. These are:
Phobos mod dool class
- std.string -> String
- std.file -> File , Path
- std.path -> Path
- std.conv -> Integer (rename to Int?)
- std.ctype -> Charater (rename to Char?)
Thats it..
The impact on DUI is also minimal. The DUI developer will notice only that DUI methods no longer return char[] and char[][] but String and String[].
Many of DUI methods overload char[] and String parameters. This make the changes to DUI applications very minimal as DUI is not a library to manipulate Strings or perform io.
here it says:
"new functionalities are always accepted (the exceptions are obvious and include malware, legal, and broken submissions)"
should say:
"new functionalities are always accepted (the exceptions are obvious and include malware, illegal, and broken submissions)"
(illegal instead of legal)