Have Visual D do imports a bit different

[Rainer Schuetze via Digitalmars-d-ide]

On 11.09.2017 11:51, EntangledQuanta wrote:
> I like to separate my code in to chunks as it's easier to manage than 
> one long flat file with a bunch of stuff in it.
> 
> Of course, we have modules... but I don't want to use modules because 
> don't want to have to setup extra structure to make the code valid for 
> modules.
> 
> Instead I use
> 
> mixin(import("file.d"));
> 
> But Visual D does not realize that this file is being use this way and 
> when I go to edit, it treats it as a module.
> 
> It would be very nice if Visual D could help out here and not just give 
> a bunch of warnings(I have to disable the files from compilation to even 
> compile) but actually do valid semantic analysis on it.
> 
> 
> e.g., suppose you have this module:
> 
> module test;
> 
> import std.stdio;
> 
> int x = 3;
> 
> void foo()
> {
>     writeln(x);
> }
> 
> 
> and you want to break it up(in real life, it's obviously going to be a 
> much more complex case):
> 
> 
> module test;
> 
> import std.stdio;
> 
> int x = 3;
> 
> void foo()
> {
>     mixin(import("A.d"));
> }
> 
> 
> and A.d:
> 
>     writeln(x);
> 
> Visual D tries and the compiler both fail at understanding this simple 
> design. It's actually very convienent because it allows one to 
> arbitrarily break down code in to chunks and it doesn't require "valid" 
> module code to get to work with normal module imports. I know you think 
> that should be done, but it is actually much more work and has it's own 
> issues for large projects.
> 
> 
> It should be rather simple for Visual D to handle this case though, 
> should it not?
> 
> 
> Maybe instead of .d files we have .dinc files.
> 
> mixin(import("A.dinc"));
> 
> and all Visual D has to do is monitor for mixin(import("some dinc 
> file")) THEN translate any error and syntax messages along with 
> intellisense to and from the file through a line number mapping.
> 
> Of course, if we import it in to multiple places the context is 
> ambiguous, but the general use case for this type of breaking up of 
> large files is to use a single mixin import. It is just a "copy and 
> paste" type of semantic but allows one to break up a larger program in 
> to smaller fragments. With modules, it is more difficult because one has 
> to encapsulate the context then push it to the import file in some way 
> and program to that encapsulation... this doesn't work for just breaking 
> stuff up and requires reprogramming. Since this fragmentation method 
> works fine semantically for the compiler, it is more of an editing/ide 
> issue that is the problem.
> 
> It has it's uses though. In large files, once one solidifies parts of 
> the program, it is nice to "move" them out of the way so one can focus 
> on the current task.  Of course, one still needs to deal with the 
> original code at points(bug fixes, updating, etc).
> 
> 
> It's sort of like code folding but a little more potent. Having the code 
> spread out among a few files vs packed in to one should not really cause 
> any difficulties for anything since it's relatively arbitrary.

I don't like string mixins too much and try to avoid them if possible. 
They bring back the trouble of the C preprocessor, though in a more 
accessible way.

Your use of mixins is rather extreme, so I don't think this is an idiom 
that should be promoted too much.

The semantic analysis has mixin support (has to be enabled in the 
language options), so completion could work (though it might not be 
perfect). PRs for adding support for intelligent file lookup for error 
messages are welcome.