new DIP47: Outlining member functions of aggregates

[Paulo Pinto]

Am 09.09.2013 02:03, schrieb Andrei Alexandrescu:
> On 9/8/13 5:33 AM, Andrej Mitrovic wrote:
>> On 9/8/13, Michel Fortin <michel.fortin at 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
>

The approach should be like in Modula-2 family, only public stuff is 
allowed in .di files.

--
Paulo