Andrei Alexandrescu: >With such a system in place, object.d can essentially gain entire control >about an entire program's memory management policy.<
This is interesting, thank you for your answer. Today you have to design a language not just for what's good for the single programmer, and not even just for what's good for a good-sized group of programmers working on a single program, but also for what's good for the community of programmers that will use the language, how they will share reusable components of programs (like the modules you can find in the Python and Perl community), you need an ecological point of view too :-) Sometimes what's good for the community is not the best for the single programmer. Languages today become successful thanks to their community, and way they are developed (for example Guido V. Rossum is very good in creating an open source community of people interested to develop the Python language and its interpreter. Walter in the last years is improving in such regard, but some further improvements can be quite useful or even necessary if he wants D2/D3 to succeed. The good thing is that Walter is not frozen in place yet, he slowly keeps im! proving still, this is probably the second most important thing to do to have success in life). So this whole design of gc/refcount has to take into account the needs of good modular programming too: what does it happen if you want to create a program using modules and packages written by different people that have different ideas/needs regarding how to manage memory. An advantage of a the current design that uses one GC is that I think such inter-parts interaction problems are quite less present. Bye, bearophile
