dool is a D Object Oriented Library to extend phobos where phobos doesn't support the OO paradigm.
Why another lib?
Will it ever get popular?
Will it split the D community?
Will it compromise the accepance of DUI?
These are the first questions that you're thinking about. Valid questions no doubt and all were considered before creating the dool project.
Why?
Isn't the D standard runtime library good enough?
The standard D runtime library, phobos, has it's 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. It's 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 isn't 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 doesn't 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 don't always agree with the choice even assuming a multi-paradigm library.
dool isn't 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 it's 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 expose 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, illegal, and broken submissions), the principle is that something is better then nothing and sometimes it's 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, it's 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.
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 and 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 it's implementation and for months nothing changed.
So those are the objectives and motivations for the new library dool.
The current versions 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.
For an up-to-date dool contents check the dool class hierrarchy
Will dool compromise the accepance of DUI?
The impact of dool on DUI is minimal.
The DUI developer will notice only that DUI methods no longer return char[] or char[][] but String or String[]. Many of DUI methods overload char[] and String parameters. DUI also uses the IO classes from dool but that's transparent to the user.
This make the changes to DUI applications very minimal as DUI is not a library to manipulate Strings or perform io. | 
