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.

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.