Kris wrote:
> "JT" <JT_member@pathlink.com> wrote
>> I think part of the confusion is lack of knowledge of how the DMD compiler
>> works. When one compiles a DMD module - it parses and performs full analysis on
>> all imported modules - and all modules they import etc.
> 
> I think most folks understand this. Is it an issue?

Ah, and this is what you meant about timestamping not being used in D. Works for me.


Sean

"Kris" <fu@bar.com> wrote in message news:dp4oq5$6qt$1@digitaldaemon.com...
> Forgive me Dave, but I just can't see how that's relevant. What you describe is not what, for example, any Fortune-500 company would consider usable.

I disagree. Take a look at C++ header files: full class 'private' members, inlined function bodies, full template bodies, etc., all must be there. It's the same issue (which is what led to the demand for exported templates, which failed). Furthermore, Java is well accepted despite no practical hiding at all.

COM/interface/factory methodology in C++ does enable full hiding, however, and if you do that in D, you get full hiding as well.

Essentially, to get *practical* implementation hiding, you have to use some form of generic indirection. Successful implementation hiding schemes have all used this in one form or another: hooking interrupts in DOS, handles in the early Mac API, double indirection needed to access DLL methods, and COM programming.

"Kris" <fu@bar.com> wrote in message news:dp4oq5$6qt$1@digitaldaemon.com...
> I can point to one side-effect that actually does help: the compiler now looks for "di" files, which means that hand-coded "implementation bridging" files can (at last!) live side-by-side with the real implementation module, eliminating some prior grief for a developer. However, this conflicts with -H rather badly, and therefore is likely to be an unintended and somewhat precarious benefit. Was that aspect considered?

Actually, it's intended. You can automatically build them, hand build them, or hand edit the automatically built one.

"Sean Kelly" <sean@f4.ca> wrote in message news:dp4r60$8e5$1@digitaldaemon.com...
> I think it's important to separate QOI features from "standard" features. Will it be necessary for all D compilers to have code coverage or profiling tools?  Of course not.  Header generation is in the same category.

That's right. I tried to make that distiction explicit in the doc. -H is not a D language feature, it's a DMD implementation feature (and one GDC will likely pick up as well).

Sean Kelly wrote:
> Kris wrote:
>> "JT" <JT_member@pathlink.com> wrote
>>> I think part of the confusion is lack of knowledge of how the DMD compiler
>>> works. When one compiles a DMD module - it parses and performs full analysis on
>>> all imported modules - and all modules they import etc.
>>
>> I think most folks understand this. Is it an issue?
> 
> Ah, and this is what you meant about timestamping not being used in D. Works for me.

I posted without thinking about this :-p.  While this may be how the compiler works (and approximately how any compiler works, so far as I'm aware), this is separate from the timestamping issue.


Sean

"Sean Kelly" <sean@f4.ca> wrote...
> Sorry :-)  I suppose I read too much into some of the text I omitted.

Mea cupla :)


>>> Another issue is that header files are touched far less frequently than implementation files.  Thus, implementation changes can be made and so long as the header remains unchanged the compiler doesn't have to rebuild dependent modules.  In large projects, this can be of tremendous value. To this end, it might be nice if DMD only touched header files for nonzero deltas (so timestamps only changed if the file contents changed).
>>
>> In C, yes. D currently does not have any such issues.
>
> How so?  I'll admit I haven't looked into how the need for recompilation is detected.


I'm sorry. I meant that D doesn't have those performance issues. Introducing D header files does, of course, introduce the synchronization problem you note. But this performance aspect is a different one from implementation hiding.


>> Ack ~ this is not about mangled headers!
>
> I had a few things going through my head and unfortunately only one of them made it out :-)  I was thinking of implementation hiding in .NET where mangling is pretty much necessary.  So what would be fitting then? The ability to generate pure headers with no inlined function calls and no private data?


That's effectively what so many requests have been about. Imported modules must be considered also. In a closed-source, proprietary environments, one shouldn't be exposing various bits of implementation or private attributes; certainly when there's no legitimate reason to do so.


>>> I think it's important to separate QOI features from "standard" features. Will it be necessary for all D compilers to have code coverage or profiling tools?  Of course not.  Header generation is in the same category.
>>
>> Is it? If, just if, people start using -H in an attempt at implementation-hiding, then other compilers will have to follow suit. After all, code will be written to take advantage of those headers (the whole point of implementation-hiding), and thus will be dependent on the way the information is exposed. Thus, once we start down that road others will have to comply.
>
> I'm not sure I understand.  The -H option must necessarily generate headers that contain much of the same symbolic information as the original module or the header will not be usable.  Hrm... perhaps instead of containing private data for alignment purposes, a pragma could be used to indicate data size?  ie.
>
> class C {
> private:
>     int x;
>     int y;
> }
>
> // translates to
>
> class C {
> pragma( pad, 8 );
> }


Pardon me if I copy a bit from another post:

"I have to say, though, that's there's a fundamental flaw exposed by trying to please two masters: you can't do implementation-hiding correctly whilst exposing partial-implementation and private attributes. And you can't provide for faster-compilation without doing so."

That's a generalization, and refers to inline-code concerns, templates, and so on.

To go one further: If D cannot, technically, expose a module or a class for external usage without exposing various proprietary private attributes and proprietary snippets of code (which in turn may reference proprietary yet private imports), then there's something very far wrong with the entire concept of D. This would cause DDL a blow, and put into question the legitimacy of using D for commercial purpose. I have, and continue to assume this is not the case.

We should refer back to Derek's example, but I'll paste it here instead (hope Derek doesn't mind):

=========================

This source file ...

//--------------------------------
import std.stdio;

private int qwerty;
class A
{
     private int x;
     void ths()
     {
       x = 1;
       }
}

void xpub()
{
     A a = new A;
     qwerty = 1;
}

private void xpriv()
{
     A b = new A;
     qwerty = 2;
}
//--------------------------------


was turned into this 'header' ...

// D import file generated from 'test.d'
import std.stdio;
private
{
     int qwerty;
}
class A
{
     private
{
     int x;
}
     void ths()
{
x = 1;
}
}
void xpub()
{
A a = new A;
qwerty = 1;
}
private
{
     void xpriv()
{
A b = new A;
qwerty = 2;
}
}
//-------------------------

but I was expecting something more like this ...

// D import file generated by hand
import std.stdio;

class A
{
     void ths(){}
}
void xpub(){}

===================


The latter is what we've been asking for (for a long time). Note that Derek also included a (non-private) import in the hand-built version? Private imports should not be exposed.

Absolutely agreed; but -H does not do this for the "indirection" case either. Nobody is asking for miracles, but the fact remains that Derek's example shows that -H is hopelessly lame at hiding the implementation. If I had a compiler that worked, I could show you exactly what I mean.

-H is no good for implementation hiding. We should stop trying to describe it as such when you yourself have said as much in prior posts.

Respectfully;

- Kris



"Walter Bright" <newshound@digitalmars.com> wrote in message news:dp52vk$dqu$1@digitaldaemon.com...
>
> "Kris" <fu@bar.com> wrote in message news:dp4oq5$6qt$1@digitaldaemon.com...
>> Forgive me Dave, but I just can't see how that's relevant. What you describe is not what, for example, any Fortune-500 company would consider usable.
>
> I disagree. Take a look at C++ header files: full class 'private' members, inlined function bodies, full template bodies, etc., all must be there. It's the same issue (which is what led to the demand for exported templates, which failed). Furthermore, Java is well accepted despite no practical hiding at all.
>
> COM/interface/factory methodology in C++ does enable full hiding, however, and if you do that in D, you get full hiding as well.
>
> Essentially, to get *practical* implementation hiding, you have to use some form of generic indirection. Successful implementation hiding schemes have all used this in one form or another: hooking interrupts in DOS, handles in the early Mac API, double indirection needed to access DLL methods, and COM programming.
> 

"Walter Bright" <newshound@digitalmars.com> wrote in message news:dp52vk$dqu$2@digitaldaemon.com...
>
> "Kris" <fu@bar.com> wrote in message news:dp4oq5$6qt$1@digitaldaemon.com...
>> I can point to one side-effect that actually does help: the compiler now looks for "di" files, which means that hand-coded "implementation bridging" files can (at last!) live side-by-side with the real implementation module, eliminating some prior grief for a developer. However, this conflicts with -H rather badly, and therefore is likely to be an unintended and somewhat precarious benefit. Was that aspect considered?
>
> Actually, it's intended. You can automatically build them, hand build them, or hand edit the automatically built one.

You can imagine the poor sod who carefully crafts his "di" file by hand (through necessity), only to find the "performance enhancing" aspects of the compiler trash his file at some later point.

This ain't good.

Kris wrote:
> "Walter Bright" <newshound@digitalmars.com> wrote in message news:dp52vk$dqu$2@digitaldaemon.com...
>> "Kris" <fu@bar.com> wrote in message news:dp4oq5$6qt$1@digitaldaemon.com...
>>> I can point to one side-effect that actually does help: the compiler now looks for "di" files, which means that hand-coded "implementation bridging" files can (at last!) live side-by-side with the real implementation module, eliminating some prior grief for a developer. However, this conflicts with -H rather badly, and therefore is likely to be an unintended and somewhat precarious benefit. Was that aspect considered?
>> Actually, it's intended. You can automatically build them, hand build them, or hand edit the automatically built one.
> 
> You can imagine the poor sod who carefully crafts his "di" file by hand (through necessity), only to find the "performance enhancing" aspects of the compiler trash his file at some later point.

But don't you have to supply a -H command-line parameter to indicate that the header should be generated?  I'm not sure it's fair to criticize DMD for what seems like user error.


Sean

In article <dp53dk$e44$1@digitaldaemon.com>, Sean Kelly says...
>
>Sean Kelly wrote:
>> Kris wrote:
>>> "JT" <JT_member@pathlink.com> wrote
>>>> I think part of the confusion is lack of knowledge of how the DMD
>>>> compiler
>>>> works. When one compiles a DMD module - it parses and performs full
>>>> analysis on
>>>> all imported modules - and all modules they import etc.
>>>
>>> I think most folks understand this. Is it an issue?
>> 
>> Ah, and this is what you meant about timestamping not being used in D. Works for me.
>
>I posted without thinking about this :-p.  While this may be how the compiler works (and approximately how any compiler works, so far as I'm aware), this is separate from the timestamping issue.
>
>
>Sean

well in C++ you only parse headers.... thats all this -H is doing. its providing a way to compile large projects without having to parse every module for every module etc. I still cant understand why people are upset because a feature exists they dont need. Its downright comedy.