Have Visual D do imports a bit different

[EntangledQuanta via Digitalmars-d-ide]

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.