DI Generation Needs your Help!

[Adam Wilson]

On Mon, 19 Dec 2011 04:57:54 -0800, so <so at so.so> wrote:

> On Mon, 19 Dec 2011 14:43:07 +0200, Jakob Ovrum <jakobovrum at gmail.com>  
> wrote:
>
>> On Monday, 19 December 2011 at 12:11:32 UTC, so wrote:
>>> On Mon, 19 Dec 2011 10:11:25 +0200, Adam Wilson <flyboynw at gmail.com>  
>>> wrote:
>>>
>>>> Everything else is left alone. Templates and mixins are not addressed  
>>>> with this code and *should* not be modified. That's where I need your  
>>>> help, the test cases I have written cover some basic scenarios but I  
>>>> don't have the capability to test these changes with the diverse code  
>>>> base that the community has created.
>>>
>>> I am not exactly sure about your problem with templates and mixins but  
>>> i'll give it a try regardless :)
>>> Since with templates there is no distinction between definition and  
>>> decleration,
>>> exposing them IMO should be solely based on thier module access  
>>> signatures.
>>>
>>> private struct A() // hide
>>> public struct B()  // expose
>>>
>>> Now if B or some another exposed structure in ".di" should call A,
>>> compiler will take care of it by outputting an error as usual.
>>
>> And if the public template tries to access the private one?
>>
>> Private module members must be treated like any other unless the  
>> compiler can prove it removed all references to the private member.
>
> You are right it was obscure, i'll try to clarify.
> By "B or some another exposed structure" i meant things resides  
> "completely" in ".di" file.
> Things like Templates, mixins and if we get them one day inlined  
> functions.
> In this scenario a "original.d" file should be interpreted as:
>
> original.d
>    public void A()()
>    private void B()()
>
> whatitwasmeant.di
>    public void A()()
>
> whatitwasmeant.d
>    private void B()()
>
> Here B can call A but not the opposite.
> A simple doesn't see B here. Things that resides completely in ".di"  
> file have no way to access the things in its ".d" file unless it wasn't  
> "exported".
> Imagine the final/generated ".di" file IS the user and the original ".d"  
> file is the library designer. While i think this is the right way, it  
> probably not that easy to implement.

So the consensus is to keep all private members/imports/etc?

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/