On Tuesday, 5 March 2013 at 12:19:17 UTC, Jacob Carlborg wrote:
> On 2013-03-05 13:01, eles wrote:
> The compiler will need to know the size of the class, for that it needs to know the instance variables.

Maybe, but private variables should have nothing to do w.r.t. the behaviour of the class, including its behaviour w.r.t. the sizeof() operator and so on.

What compiler does know and what the user care about are different things.

On 2013-03-05 13:48, eles wrote:

> Maybe, but private variables should have nothing to do w.r.t. the
> behaviour of the class, including its behaviour w.r.t. the sizeof()
> operator and so on.
>
> What compiler does know and what the user care about are different things.

True. But how does the compiler get this information if you're using a pre compiled library and a .di file?

-- 
/Jacob Carlborg

On Tuesday, 5 March 2013 at 14:40:57 UTC, Jacob Carlborg wrote:
> On 2013-03-05 13:48, eles wrote:
> True. But how does the compiler get this information if you're using a pre compiled library and a .di file?

I imagine that a similar question was asked about the virtual methods...
Hide that into a pre-compiled's library special field, for example.
The runtime would maintain a "private data description" information about each class, read from the module. Private variables would simply not be put into the class, but in run-time specific data.

On Tuesday, 5 March 2013 at 12:20:15 UTC, Dicebot wrote:
> On Tuesday, 5 March 2013 at 10:41:36 UTC, Jacob Carlborg wrote:
>> On 2013-03-05 09:48, Dicebot wrote:
>>
>>> I can find nothing on the topic of "separation" issue down that link. In
>>> fact I have never met a C/C++ programmer saying fact of having a
>>> separate headers is a problem, it was a loved feature if anything.
>>> Problem was the way it was designed, via pre-processor. D fixes this by
>>> introducing real symbolic imports and that is good, but completely
>>> irrelevant to the topic of separation of interface and implementation.
>>
>> We are all here :)
>
> Well, that is why I am so surprised and asking for rationale with better explanation than "it is obvious". I am rather astonished by an overall negative reaction to a long awaited (by me) Andrei proposal.

Clearly there's a misunderstanding going on somewhere. For example when I say "code duplication" you say "There is close to zero code duplication." but from my POV there clearly is code duplication and it is indeed significant and completely unnecessary. Also my understanding of what a module accomplishes is a super set of what you think a module accomplishes, i.e., I include that it solves the code duplication problem, you don't.

I agree that the current method of automated .di generation is a failure, but I think it is a failure only because the programmer has no control over specifying what goes into the .di file from within the module source, and that the automated .di generation and maintenance implementation is incomplete.

At this point in the discussion, I don't see a sound reason why the automated .di generation cannot be fixed (proposed solutions haven't even been discussed in any depth), and regressing back to manual separation of code seems like a "quick fix" hack that introduces a set of serious problems that cancel out the benefits and probably make the situation worse.

You seem to support the idea of using manual .di generation and maintenance, which implies to me that you think automated .di generation cannot succeed, is this correct? If so, then I have to ask why?

--rt

On Tuesday, 5 March 2013 at 12:01:54 UTC, eles wrote:
> On Monday, 4 March 2013 at 06:18:35 UTC, Manu wrote:
>> +1_000_000_000
>>
>> Yes please!
>> It's near impossible to get a brief overview of a class at a glance in D!
>
> Exactly for this reason, what about make this way at least the recommended way, if not the single one?
>
> What is to lose? As about what to win, basically each .d file will carry its .di file (class definition) inside it, and the latter can be easily extracted (both visually and automatically).
>
> Just one note: please allow that the private variables of a class (those that are not exposed outside the file) be declarable outside the main definition of the class, that is with the . syntax. This will completely make declaration and implementation independent, to the point that the class definition is an interface and nothing else.

This is what I'd like to see happen with modules which seems to be in agreement with what you are proposing: The module source file should contain everything needed to automatically generate and maintain a .di file. There should no need to manually maintain a .di file.

How we accomplish that goal is an implementation detail, however I fully agree that something needs to be done and it should be done without any need to manually maintain separate .di files.

--rt

On Tue, Mar 05, 2013 at 06:39:07PM +0100, Rob T wrote:
> On Tuesday, 5 March 2013 at 12:01:54 UTC, eles wrote:
> >On Monday, 4 March 2013 at 06:18:35 UTC, Manu wrote:
> >>+1_000_000_000
> >>
> >>Yes please!
> >>It's near impossible to get a brief overview of a class at a
> >>glance in D!
> >
> >Exactly for this reason, what about make this way at least the recommended way, if not the single one?
> >
> >What is to lose? As about what to win, basically each .d file will
> >carry its .di file (class definition) inside it, and the latter
> >can be easily extracted (both visually and automatically).
> >
> >Just one note: please allow that the private variables of a class (those that are not exposed outside the file) be declarable outside the main definition of the class, that is with the . syntax. This will completely make declaration and implementation independent, to the point that the class definition is an interface and nothing else.
> 
> This is what I'd like to see happen with modules which seems to be in agreement with what you are proposing: The module source file should contain everything needed to automatically generate and maintain a .di file. There should no need to manually maintain a .di file.

+1.  It should be the compiler's job to export the public API of a given .d module, not the programmer's. By default, it should export only public members.

Optionally, we can use UDAs to override compiler defaults in certain cases, where it's necessary. Ideally, such cases will be very rare.


> How we accomplish that goal is an implementation detail, however I fully agree that something needs to be done and it should be done without any need to manually maintain separate .di files.

+1.

Separate maintenance of header files in C/C++ has always been a pain and source of inconsistencies. It's one thing when you have a small dedicated team working on the same codebase; I have seen such code in projects that were handed around to different people (due to the usual reasons -- turnover, company reorg, etc.), and inevitably, the headers go out of sync with the implementation files.

I've actually seen (and fixed) a case of two C functions that were declared with the same name in two different libraries, and in one module, the wrong library was linked in, thus linking the call to the wrong function, causing strange runtime problems that no amount of staring at the source code would reveal the reason for. The #include was perfectly correct; but the problem was that the declaration was detached from the implementation, so the compiler has no way to check for this kind of problem.

Not to mention the silliness of having to copy-n-paste function prototypes in two places -- in this day and age, why are we still promoting such error-prone manual hackish ways of coding? Such things should be automated!

D's module system is the beginning of a sane handling of such issues. Let's not go back to the bad ole split header/implementation approach. It should be the compiler's job to extract the public API of a module *automatically*, so that consistency is guaranteed. No room for human error.


T

-- 
The best compiler is between your ears. -- Michael Abrash

05-Mar-2013 21:39, Rob T пишет:
> On Tuesday, 5 March 2013 at 12:01:54 UTC, eles wrote:
>> On Monday, 4 March 2013 at 06:18:35 UTC, Manu wrote:
>>> +1_000_000_000
>>>
>>> Yes please!
>>> It's near impossible to get a brief overview of a class at a glance
>>> in D!
>>
>> Exactly for this reason, what about make this way at least the
>> recommended way, if not the single one?
>>
>> What is to lose? As about what to win, basically each .d file will
>> carry its .di file (class definition) inside it, and the latter can be
>> easily extracted (both visually and automatically).
>>
>> Just one note: please allow that the private variables of a class
>> (those that are not exposed outside the file) be declarable outside
>> the main definition of the class, that is with the . syntax. This will
>> completely make declaration and implementation independent, to the
>> point that the class definition is an interface and nothing else.
>
> This is what I'd like to see happen with modules which seems to be in
> agreement with what you are proposing: The module source file should
> contain everything needed to automatically generate and maintain a .di
> file. There should no need to manually maintain a .di file.
>

Leverage UDAs ?

> How we accomplish that goal is an implementation detail, however I fully
> agree that something needs to be done and it should be done without any
> need to manually maintain separate .di files.
>
> --rt


-- 
Dmitry Olshansky

On Tuesday, 5 March 2013 at 17:22:52 UTC, Rob T wrote:
> Clearly there's a misunderstanding going on somewhere. For example when I say "code duplication" you say "There is close to zero code duplication." but from my POV there clearly is code duplication and it is indeed significant and completely unnecessary. Also my understanding of what a module accomplishes is a super set of what you think a module accomplishes, i.e., I include that it solves the code duplication problem, you don't.

Do you consider necessity to duplicate method signature when overriding in descendant to be a significant code duplication too? Because I fail to see the difference in this two cases.

> I agree that the current method of automated .di generation is a failure, but I think it is a failure only because the programmer has no control over specifying what goes into the .di file from within the module source, and that the automated .di generation and maintenance implementation is incomplete.
>
> At this point in the discussion, I don't see a sound reason why the automated .di generation cannot be fixed (proposed solutions haven't even been discussed in any depth), and regressing back to manual separation of code seems like a "quick fix" hack that introduces a set of serious problems that cancel out the benefits and probably make the situation worse.

I do not object better automatic .di generation, that is good for sure. But I do object opposing proposed simplification of going other way around. Why do you call it "regressing" if it changes nothing in current behavior? It will considerably improve my usage scenario (start with .di, write .d after) and won't affect yours (write only .d)

> You seem to support the idea of using manual .di generation and maintenance, which implies to me that you think automated .di generation cannot succeed, is this correct? If so, then I have to ask why?

"Success" is not the right term here, automated generation helps different development model - when you just go and write stuff you want, compile it and provide something to import to use it. Manual .di writing is all about strict separation of interface and implementation, not only logical separation, but a physical one. I find it a very solid thinking model - removing possibility to see an implementation details even by an accident and removing the temptation to alter interface few extra times by keeping it far from current context. Automatic generation won't help it because I _do want to maintain them as separate entities_.

Also all maintenance issues mentioned in this thread for C have roots in header being processed in scope of importer translation unit, not actually the fact that it is separate. For example, naming clash at linking stage is not possible as all names are implicitly in modules namespace.

On Tuesday, 5 March 2013 at 19:14:08 UTC, Dicebot wrote:
>
> Do you consider necessity to duplicate method signature when overriding in descendant to be a significant code duplication too? Because I fail to see the difference in this two cases.

I think there is a difference. For example the compiler will complain when there's a typo, as opposed to getting obfuscated linker errors. No matter if there *is* a sane way to prevent duplication of function overrides, then I'll support it over duplication. This is a common concept, you should *allays* want to avoid unnecessary duplications as every line of extra code you add will exponentially increase the amount of effort required to maintain bug free code.

>
> I do not object better automatic .di generation, that is good for sure. But I do object opposing proposed simplification of going other way around. Why do you call it "regressing" if it changes nothing in current behavior? It will considerably improve my usage scenario (start with .di, write .d after) and won't affect yours (write only .d)

You'll need to explain more what you are trying to accomplish because I sincerely cannot understand what you are arguing for. Why would anyone ever want to start off with a .di interface?

>
> "Success" is not the right term here, automated generation helps different development model - when you just go and write stuff you want, compile it and provide something to import to use it. Manual .di writing is all about strict separation of interface and implementation, not only logical separation, but a physical one. I find it a very solid thinking model - removing possibility to see an implementation details even by an accident and removing the temptation to alter interface few extra times by keeping it far from current context. Automatic generation won't help it because I _do want to maintain them as separate entities_.

Again this goes back to previous question: Why would you ever want to maintain a separation of interface from source? I am fully aware of the need to generate a separation for a variety of reasons (source code hiding being a significant reason for one) but I fail to see any reason why the process ever has to be a manual effort. Perhaps you can give me an example?

> Also all maintenance issues mentioned in this thread for C have roots in header being processed in scope of importer translation unit, not actually the fact that it is separate. For example, naming clash at linking stage is not possible as all names are implicitly in modules namespace.

Perhaps then, what I think is the most significant point of all is being missed. I can see a very clear reason why in terms of source code, the interface and implementation must not be be separated. Automated .di generation is a means to solve the need for separation when distributing libraries, whoever what goes in the .di should not be considered as your "source code" because it should be auto generated from the source (eg your .o files are not source code in the same way). I

f there's ever a real reason to manually maintain a .di, then it's the same as having to hex edit a .o file to make it work, ie. the compiler is busted!

--rt

I curse the lack of an edit feature!

Correction of my main point:

------------

... whatever goes in the .di should not be considered as your "source code" because it should be auto generated from the source (eg your .o files are not source code in the same way). If there's ever a real reason to manually maintain a .di, then it's the same as having to hex edit a .o file to make it work,
ie. the compiler is busted!

------------

--rt