• EntangledQuanta (64/64) Sep 11 2017 I like to separate my code in to chunks as it's easier to manage
• Rainer Schuetze (10/103) Sep 13 2017 I don't like string mixins too much and try to avoid them if possible.

EntangledQuanta <EQ universe.com> writes:

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.

Rainer Schuetze <r.sagitario gmx.de> writes:

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.