On Saturday, 17 November 2012 at 23:08:04 UTC, maarten van damme
wrote:
Why is so much built in to druntime? creating classes, AA's,....
Is it normal? does c++ do the same thing?
Why wasn't opted for making opIndex overloadable with other
objects so
AA's could be moved out of druntime and in phobos?
I have no experience with language design but wouldn't it be
great if
druntime was more modular to make porting (and stripping) of
features
for for example embedded platforms more easy?
And is somewhere documented which functions need to be
implemented in druntime?
Druntime is a mixture of functions that the application may call,
functions that the generated code calls and internal library
functions. As pointed out earlier in this thread, there is no
more documentation than those generated from the source files.
They tell how to use the functions but does not tell when and why
we need it.
I started with my test class and object.d and added files one by
one and commented out some features until all references were
solved in that particular case. Nearly every file in the library
is related to some d construction or keyword. If I use a
construction in my application, I need a file from the library.
Unfortunately, the whole file is included from the library even
if I need a single funtion from it.
The library has lots of version dependencies. First it has been
made for win/mac/linux, then it has been ported to gdc. The next
challenge is to add support for all mobile platforms and embedded
systems with no os at all. In my opinion the version system will
not work any more when we have 10 different systems to support.
We should have abstract classes an put the real implementation to
os specific directory. Then we make that directory as import
directory.
It might also be good to have a minimum implementation in
configure. That would include only the necessary files and define
version=minimum. This option would leave out as much as possible
from the code. To make it work with all possible configuration
may not be an easy task.
All these takes lots of time and work. If the library is only for
gdc, it would be simpler. To have a library that is totally
different from the dmd version might not be a good idea. A
library with different features and bugs may reduce the amount of
possible users and it is harder to get people to maintain it.
