Jesse Phillips Wrote: > > It makes everything much clearer and creates a bunch of opportunities for > > further development. > > I don't see such benefit.
It's easier for the programmer to find the module if it shares the name with the file. Especially true when faced with other people's code, or code that's more than 6 months old, or just large projects. The same goes for packages and directories. The relationship is clear: each file defines a module. The natural thing would be to have them bear the same name. It lets the compiler traverse dependencies by itself. This is good for the following reasons: 1) You don't need build tools, makefiles. Just "dmd myApp.d". Do you know how many build tools there are, each trying to do the same thing. They are at disadvantage to the compiler because the compiler can do conditional compiling and generally understands the code better than other programs. There's also extra work involved in keeping makefiles current. They are just like header files are for C/C++ -- an old solution. 2) The compiler can do more optimisation, inlining, reduction and refactoring. The compiler also knows which code interacts with other code and can use that information for cache-specific optimisations. Vladimir suggested it would open the door to new language features (like virtual templated methods). Generally I think it would be good for templates, mixins and the like. In the TDPL book Andrei makes hints about future AST-introspection functionality. Surely access to the source would benefit from this. It would simplify error messages now caused by the linker. Names within a program wouldn't need to be mangled. More information about the caller / callee would also be available at the point of error. It would also be of great help to third-party developers. Static code analysers (for performance, correctness, bugs, documentation etc), packet managers... They could all benefit from the simpler structure. They wouldn't have to guess what code is used or built (by matching names themselves or trying to interpret makefiles). It would be easier for novices. The simpler it is to build a program the better. It could be good for the community of D programmers. Download some code and it would fit right in. Naming is a little bit of a Wild West now. Standardised naming makes it easier to sort, structure and reuse code. > > I'd create a branch (in git or mercury) for that task, it's quick and dirt > > cheap, very easy to switch to and from, and you get the diff for free. > > Right, using such tools is great. But what if you are like me and don't have > a dev environment set up for Phobos, but I want to fix some module? Do I have > to setup such an environment or through the file in a folder std/ just do > some work on it? You have compilers, linkers and editors but no version control system? They are generally very easy to install and use. When you have used one for a while you wonder how you ever got along without it before. In git for example, creating a feature branch is one command (or two clicks with a gui). There you can tinker and experiment all you want without causing any trouble with other branches. I usually create a new branch for every new feature. I do some coding on one, switch to another branch and fix something else. They are completely separate. When they are done you merge them into your mainline.
