"Nick Sabalausky" <[email protected]> wrote in message news:[email protected]... > "bearophile" <[email protected]> wrote in message > news:[email protected]... >> Clay Smith: >> >>>I would like my all.d files to not give errors :o< >> >> "all.d" files are a hack used to patch one of the minor holes of the >> current D module system. The right way to do that is with a syntax like >> (that must not import the 'foo' name too in the current namespace, only >> the names inside "std.foo"): >> >> import std.foo: *; >> >> Every part of a language needs to be designed with care. Approximate >> designs with several holes aren't enough. >> > > I used to think so, but I'm not so sure anymore. In my Goldie project, one > of the modules ("goldie.file") is something with a whole lot of types and > details about loading a .cgt file. In the vast majority of use-cases, the > Goldie library user has no reason to use any of those directly, so as > useful as "goldie.all" is, it would be pointless for me to include that > "goldie.file" in "goldie.all", which is exactly what "goldie.*" would do > automatically if it existed. Now, certainly, I could just mark everything > in "goldie.file" as private, but I do want people to be able to import and > use it directly if they want to (Ex, if they want to use Goldie as a > springboard for their own .cgt-file handling routines). > > Plus, I'll often have renamed and deliberately unused source files in the > same directory as "real" modules, and I wouldn't want them automatically > grabbed by ".*". I suppose I could change their extension, but then the > editor would get confused, and I'd have to work around that, etc...
Another Goldie-derived example of ".all" being more useful than ".*": I'm building a tool that generates a statically-compiled and linked D source version of a grammar (normally they're loaded at runtime from a file). Unless I change my mind, I intend for these to be used with "import somelang = myapp.staticlangs.somelang.all", so that multiple static langauges can be used together (Ie, "d.Token", "haxe.Token", "js.Token", whatever). I originally had the generation tool give unique names to each type (Ie, "Token_haxe", "Token_js", etc), but I'm thinking now the renamed import approach is probably more appropriate and less hack-ish, and comes with more built-in flexibility. But anyway, suppose someone has a project with multiple languages like this (ex "myapp.staticlangs.haxe.all" and "myapp.staticlangs.js.all", and maybe a couple others). If they tried an "import myapp.staticlangs.*" approach, that just wouldn't work, because they're designed to be used as renamed imports. But they could easily create a "myapp.staticlangs.all" (or hell, I could even generate one) that would automatically do the correct renamed imports. Anyway, just another thing that ".*" importing can't really handle.
