On 9/8/13 5:33 AM, Andrej Mitrovic wrote:
On 9/8/13, Michel Fortin <michel.for...@michelf.ca> wrote:
So I'd like to suggest this: allow a .d file to "import" its corresponding
.di file.
This is actually what Andrei proposed as well.
I have to say I was a lot more in favor of the proposal before this thread.
The problem as I see it has two facets:
1. Code duplication
2. Modularity and logistics
Regarding (1), we currently force duplication of the entire class
layout. My understanding is that this is the way it's done:
// file acme.di
class A {
int x;
double y;
void fun();
}
// file acme.d
// cannot import acme.di
class A {
int x;
double y;
void fun() { ... }
}
The fact that acme.d cannot import acme.di is an unforced error of
embarrassing proportions and consequence. That should be fixed yesterday
no matter how we proceed otherwise.
The problem with acme.d not having access to acme.di is that any error
in duplicating the layout of A (e.g. swapping x and y or adding some
other members etc) will have undefined behavior, and there is no
reasonable way for the compiler to check against that.
Assuming that bug is fixed, the problem of duplication remains - all
state of the class must be duplicated.
(I also suspect constructors might need to be white-boxed (i.e.
available in the .di) for raw/cooked typechecking, but I'm not sure.)
If we go with DIP47, the duplication of state goes away. However we have
a distinct problem - modularity, which segues into (2).
Allowing out-of-module implementations of individual methods poses
additional modularity problems. Consider:
// file acme.di
class A {
int x;
double y;
void fun();
}
private int a;
private void gun();
// file acme.d
// assume we solve the import problem
import acme;
void A.fun() { gun(); a = 42; }
If A.fun() were defined inside acme.di, it would have access to gun()
and a. Defining it outside asks the question - do we allow such access,
or not?
Intuitively the body of a method should not be all too sensitive to
where it's placed, so that argues in favor of visibility.
D's module system has always favored a file-granular approach, e.g.
private stuff is module-private. This notion of spilling private access
outside the file into methods defined in various other files works
against that nice tenet.
So it looks there's no obvious and obviously good solution. Probably the
first one is more sensible.
Andrei
