Carlos Santander wrote:
> John Reimer escribió:
>>
>> Okay, now I see why there is so much confusion going on with the addition of this feature.  There are two problems to be solved: one is the issue of implementation hiding; the other is the issue of compiler performance.  I think most of us mistook the di file generator to be a solution for implementation hiding for closed source projects. Obviously we got the wrong idea about the whole thing.
>>
>> If di files serve the same purpose as "precompiled headers," obviously there is no consideration whatsoever for implementation hiding (and there never was any such intention).
>>
>> Good to know.  Personally, I was less interested in compile performance and more interested in implementation hiding.  The -H flag, therefore, will not be of much use to me.
>>
>> -JJR
> 
> Same here. I mean, I also agree with all of you guys that -H should do something different.
> 
> BTW, IIRC, digc did something like that. Does anybody know if it still compiles? Did it really do that?
> 

I think digc was updated several months ago by Burton to do a whole lot more than it used to do.  It might be worth checking out.  I distinctly recall that it received very little attention when he announced the update, which was a surprise to me.  I haven't looked into it much myself, though.

-JJR

J C Calvarese wrote:
> In article <dp27tj$19f5$1@digitaldaemon.com>, John Reimer says...
>> Okay, now I see why there is so much confusion going on with the addition of this feature.  There are two problems to be solved: one is the issue of implementation hiding; the other is the issue of compiler performance.  I think most of us mistook the di file generator to be a solution for implementation hiding for closed source projects. Obviously we got the wrong idea about the whole thing.
>>
>> If di files serve the same purpose as "precompiled headers," obviously there is no consideration whatsoever for implementation hiding (and there never was any such intention).
>>
>> Good to know.  Personally, I was less interested in compile performance and more interested in implementation hiding.  The -H flag, therefore, will not be of much use to me.
>>
>> -JJR
> 
> I have to say as fast as DMD compiles files, I was more interested in seeing
> headers stripped to the bone than optimally stripped, too (I really don't want
> that to sound as weird as it does, but I think "stripped aggressively" would be
> worse). I doubt that I would personally use it for hiding code (my code isn't
> interesting enough to bother hiding), but it seems like a neat thing to do. 
> 
> But I was thinking... If the magic happens in the (open source) front-end, it
> might not be that hard for an enterprising individual to alter the compiler to
> leave out the optimizations. I found in "mars.c" where the command line option
> "-H" is detected, and I followed the program flow to "hdrgen.c". But that's as
> far as I got before I lost interest. Time for sleep anyway. ;)
> 
> jcc7

It's probably possible.  Or they could just start on a project separate from the compiler that creates the headers.  Like Carlos mentioned, digc may already do this.

-JJR

Kyle Furlong wrote:
> John Reimer wrote:

>>
>> Okay, now I see why there is so much confusion going on with the addition of this feature.  There are two problems to be solved: one is the issue of implementation hiding; the other is the issue of compiler performance.  I think most of us mistook the di file generator to be a solution for implementation hiding for closed source projects. Obviously we got the wrong idea about the whole thing.
>>
>> If di files serve the same purpose as "precompiled headers," obviously there is no consideration whatsoever for implementation hiding (and there never was any such intention).
>>
>> Good to know.  Personally, I was less interested in compile performance and more interested in implementation hiding.  The -H flag, therefore, will not be of much use to me.
>>
>> -JJR
> 
> Right on John. Walter, what is your answer for closed source implementation hiding?

I think Walter already answered this question in a previous post in this thread.  If I understand correctly, he basically detailed how implementation hiding is nigh to impossible to do effectively.  I'm not sure if he meant that it's not worth trying to program a solution because data can't be effectively hidden or that the difficultly is not worth the effort.

I just want to clarify that my idea of implementation-hiding really didn't entail encrypted libraries.  I know somebody could find out implementation details if they really wanted to.  The idea, much like the Modula 2 and 3 interface definition files, is merely to separate the details: (1) so that it isn't /easy/ to see implementation details and (2) so that we have a summary of the features a library provides.  A nifty side effect is that there's probably increase compiler performance.

In the end though, maybe something like DDL (www.dsource.org) will solve all our problems in some way.  Eliminating the need for the compiler to parse a header altogether may be a big step forward.

Also, while I feel that the -H option seems to be more of distraction from fixing higher priority items in D, it may do well for us at some point; I'm just hoping, though, that all the bugs it introduces don't take up Walter's time.

A tool like this could theoretically be separate from the compiler. That may be the best solution in the end if it's too much work to maintain. I vaguely remember arguments to this end being made months to a year or so before.

-JJR

Ivan Senji wrote:
> bobef wrote:
>> Walter Bright wrote:
>>
>>> This incorporates a new 'header' generator capability, written by Dave
>>> Fladebo, now working!
>>>
>>> http://www.digitalmars.com/d/changelog.html
>>>
>>>
>>
>>
>> I play OpenTTD all night and in the morning see what happens :)
> 
> Wow! It is one of the *best* games I ever played. It is great to see there are more fans.


Hmmm... I've never tried it before.  I'll have to take a look.

-JJR

Walter Bright wrote:
>> How can I help? I know I can /donate/ library code and documentation, but
>> the core language is still where the pre-1.0 issues lie. And even when I
>> have given you library fixes, they are still to appear. I guess I don't
>> really understand your organization's development processes.
> 
> It's mainly driven by 1) what people feel like contributing and 2) things that are blocking use of D. 

I believe Derek is asking how he can help the development of D. There is no indication that many of the things that need to be implemented/fixed are even being considered yet. Also, I have seen complaints from a few people now that their fixes aren't making it into phobos.

Chris

Ivan Senji wrote:
> bobef wrote:
>> Walter Bright wrote:
>>
>>> This incorporates a new 'header' generator capability, written by Dave
>>> Fladebo, now working!
>>>
>>> http://www.digitalmars.com/d/changelog.html
>>>
>>>
>>
>>
>> I play OpenTTD all night and in the morning see what happens :)
> 
> Wow! It is one of the *best* games I ever played. It is great to see there are more fans.

Woah!  I didn't realize that I needed the original game graphics in order to make this work.  So much for that.

-JJR

Just to clarify a couple of minor things:

As John noted, implementation hiding is not about encryption ~ it's about supporting closed-source development.

D /does/ support implementation hiding, and has done for a long time. What's been missing is a nice, simple, automated, standard, and compiler-supported way to generate a bridge between the "hidden" implementation, and client usage thereof. It's always been done manually, and it's easy to get confused over which file is which since there's common module names involved etc.

One way to approach information hiding is to use Interfaces in conjunction with a Factory pattern. There's been a couple of trivial examples posted in this thread, but the general idea is that Interfaces are used to abstract away all implementation details, and one or more public functions are exposed in a "bridging module" to create instances on a clients behalf.

Another approach to implementation hiding is to simply strip out existing method bodies and leave the bare declarations, along with any enums and/or typedefs they may use. Many requests have been made for an automated tool to do exactly this: which would also work well for the Interface approach noted above. The end result would be the same in both cases ~ a secondary "declaration only" file would be produced ~ which would be used by a client as a means to get the appropriate code linked. In all cases, the client is expected to know nothing of, nor care about, the implementation under the hood.

This is where a misunderstanding arose with -H which, as it turns out, has no real value with respect to the above. Thus, D does not have a tool to help produce a client-binding from an implementation ~ you /still/ have to do that manually. That doesn't mean it can't be done, but it can certainly be a chore, and it would be good to get some standardization in the mechanics of it (such as a standard file-extension, for example, such that the conflict over module names can be better managed).

So ~

1) D still needs a much more solid *story* for closed-source development. Without it, one could argue it deserves to remain a niche language. Note that this is not a technical hurdle, but it's one that has repeatedly failed to be passed. All it needs is a little TLC and attention.

2) The -H flag is apparently for something else entirely.


Hope that helps?

- Kris



"John Reimer" <terminal.node@gmail.com> wrote
> Kyle Furlong wrote:
>> John Reimer wrote:
>
>>>
>>> Okay, now I see why there is so much confusion going on with the addition of this feature.  There are two problems to be solved: one is the issue of implementation hiding; the other is the issue of compiler performance.  I think most of us mistook the di file generator to be a solution for implementation hiding for closed source projects. Obviously we got the wrong idea about the whole thing.
>>>
>>> If di files serve the same purpose as "precompiled headers," obviously there is no consideration whatsoever for implementation hiding (and there never was any such intention).
>>>
>>> Good to know.  Personally, I was less interested in compile performance and more interested in implementation hiding.  The -H flag, therefore, will not be of much use to me.
>>>
>>> -JJR
>>
>> Right on John. Walter, what is your answer for closed source implementation hiding?
>
> I think Walter already answered this question in a previous post in this thread.  If I understand correctly, he basically detailed how implementation hiding is nigh to impossible to do effectively.  I'm not sure if he meant that it's not worth trying to program a solution because data can't be effectively hidden or that the difficultly is not worth the effort.
>
> I just want to clarify that my idea of implementation-hiding really didn't entail encrypted libraries.  I know somebody could find out implementation details if they really wanted to.  The idea, much like the Modula 2 and 3 interface definition files, is merely to separate the details: (1) so that it isn't /easy/ to see implementation details and (2) so that we have a summary of the features a library provides.  A nifty side effect is that there's probably increase compiler performance.
>
> In the end though, maybe something like DDL (www.dsource.org) will solve all our problems in some way.  Eliminating the need for the compiler to parse a header altogether may be a big step forward.
>
> Also, while I feel that the -H option seems to be more of distraction from fixing higher priority items in D, it may do well for us at some point; I'm just hoping, though, that all the bugs it introduces don't take up Walter's time.
>
> A tool like this could theoretically be separate from the compiler. That may be the best solution in the end if it's too much work to maintain. I vaguely remember arguments to this end being made months to a year or so before.
>
> -JJR

I forgot to note that DDL does not help here at all. On the contrary, DDL firmly places a generously sized spotlight directly upon the issue.

- Kris


"Kris" <fu@bar.com> wrote in message news:dp3sve$2hm8$1@digitaldaemon.com...
> Just to clarify a couple of minor things:
>
> As John noted, implementation hiding is not about encryption ~ it's about supporting closed-source development.
>
> D /does/ support implementation hiding, and has done for a long time. What's been missing is a nice, simple, automated, standard, and compiler-supported way to generate a bridge between the "hidden" implementation, and client usage thereof. It's always been done manually, and it's easy to get confused over which file is which since there's common module names involved etc.
>
> One way to approach information hiding is to use Interfaces in conjunction with a Factory pattern. There's been a couple of trivial examples posted in this thread, but the general idea is that Interfaces are used to abstract away all implementation details, and one or more public functions are exposed in a "bridging module" to create instances on a clients behalf.
>
> Another approach to implementation hiding is to simply strip out existing method bodies and leave the bare declarations, along with any enums and/or typedefs they may use. Many requests have been made for an automated tool to do exactly this: which would also work well for the Interface approach noted above. The end result would be the same in both cases ~ a secondary "declaration only" file would be produced ~ which would be used by a client as a means to get the appropriate code linked. In all cases, the client is expected to know nothing of, nor care about, the implementation under the hood.
>
> This is where a misunderstanding arose with -H which, as it turns out, has no real value with respect to the above. Thus, D does not have a tool to help produce a client-binding from an implementation ~ you /still/ have to do that manually. That doesn't mean it can't be done, but it can certainly be a chore, and it would be good to get some standardization in the mechanics of it (such as a standard file-extension, for example, such that the conflict over module names can be better managed).
>
> So ~
>
> 1) D still needs a much more solid *story* for closed-source development. Without it, one could argue it deserves to remain a niche language. Note that this is not a technical hurdle, but it's one that has repeatedly failed to be passed. All it needs is a little TLC and attention.
>
> 2) The -H flag is apparently for something else entirely.
>
>
> Hope that helps?
>
> - Kris
>
>
>
> "John Reimer" <terminal.node@gmail.com> wrote
>> Kyle Furlong wrote:
>>> John Reimer wrote:
>>
>>>>
>>>> Okay, now I see why there is so much confusion going on with the addition of this feature.  There are two problems to be solved: one is the issue of implementation hiding; the other is the issue of compiler performance.  I think most of us mistook the di file generator to be a solution for implementation hiding for closed source projects. Obviously we got the wrong idea about the whole thing.
>>>>
>>>> If di files serve the same purpose as "precompiled headers," obviously there is no consideration whatsoever for implementation hiding (and there never was any such intention).
>>>>
>>>> Good to know.  Personally, I was less interested in compile performance and more interested in implementation hiding.  The -H flag, therefore, will not be of much use to me.
>>>>
>>>> -JJR
>>>
>>> Right on John. Walter, what is your answer for closed source implementation hiding?
>>
>> I think Walter already answered this question in a previous post in this thread.  If I understand correctly, he basically detailed how implementation hiding is nigh to impossible to do effectively.  I'm not sure if he meant that it's not worth trying to program a solution because data can't be effectively hidden or that the difficultly is not worth the effort.
>>
>> I just want to clarify that my idea of implementation-hiding really didn't entail encrypted libraries.  I know somebody could find out implementation details if they really wanted to.  The idea, much like the Modula 2 and 3 interface definition files, is merely to separate the details: (1) so that it isn't /easy/ to see implementation details and (2) so that we have a summary of the features a library provides.  A nifty side effect is that there's probably increase compiler performance.
>>
>> In the end though, maybe something like DDL (www.dsource.org) will solve all our problems in some way.  Eliminating the need for the compiler to parse a header altogether may be a big step forward.
>>
>> Also, while I feel that the -H option seems to be more of distraction from fixing higher priority items in D, it may do well for us at some point; I'm just hoping, though, that all the bugs it introduces don't take up Walter's time.
>>
>> A tool like this could theoretically be separate from the compiler. That may be the best solution in the end if it's too much work to maintain. I vaguely remember arguments to this end being made months to a year or so before.
>>
>> -JJR
>
> 

Kris wrote:
> Just to clarify a couple of minor things:
> 
> As John noted, implementation hiding is not about encryption ~ it's about supporting closed-source development.
> 
> D /does/ support implementation hiding, and has done for a long time. What's been missing is a nice, simple, automated, standard, and compiler-supported way to generate a bridge between the "hidden" implementation, and client usage thereof. It's always been done manually, and it's easy to get confused over which file is which since there's common module names involved etc.
> 
> One way to approach information hiding is to use Interfaces in conjunction with a Factory pattern. There's been a couple of trivial examples posted in this thread, but the general idea is that Interfaces are used to abstract away all implementation details, and one or more public functions are exposed in a "bridging module" to create instances on a clients behalf.
> 
> Another approach to implementation hiding is to simply strip out existing method bodies and leave the bare declarations, along with any enums and/or typedefs they may use. Many requests have been made for an automated tool to do exactly this: which would also work well for the Interface approach noted above. The end result would be the same in both cases ~ a secondary "declaration only" file would be produced ~ which would be used by a client as a means to get the appropriate code linked. In all cases, the client is expected to know nothing of, nor care about, the implementation under the hood.
> 
> This is where a misunderstanding arose with -H which, as it turns out, has no real value with respect to the above. Thus, D does not have a tool to help produce a client-binding from an implementation ~ you /still/ have to do that manually. That doesn't mean it can't be done, but it can certainly be a chore, and it would be good to get some standardization in the mechanics of it (such as a standard file-extension, for example, such that the conflict over module names can be better managed).
> 
> So ~
> 
> 1) D still needs a much more solid *story* for closed-source development. Without it, one could argue it deserves to remain a niche language. Note that this is not a technical hurdle, but it's one that has repeatedly failed to be passed. All it needs is a little TLC and attention.
> 
> 2) The -H flag is apparently for something else entirely.
> 
> 
> Hope that helps?
> 
> - Kris
> 
> 

Well said, Kris. Much better than I could put into words.  Thanks!

-JJR

In article <dp3132$1r9i$1@digitaldaemon.com>, bobef says...
>I play OpenTTD all night and in the morning see what happens :) Seriously. I won't participate in the dispute because I am not 100% sure I fully understand it (I am weak with all these programming terms :),

Really, I think it's been more of a misunderstanding than anything else. When Walter announced that DMD 0.142 could generate header, a few people started salivating at the thought of having the ability to hide the implementation of files. It's been request quite a few times, and I'd rather be able to tell them about "the H switch" than have to teach someone how to do it manually.

But unfortunately, when these eager D citizens tried out the new compiler function they realized something was terribly wrong. The compiler wouldn't hide things that one would expect it to hide. "Hey, Walter, I think it's broken," they say.

"No," says Walter. "That's how it's supposed to work. Unless it crashes -- I'll fix the things that make it crash."

And I'm not saying that what it does isn't useful. Obviously, it must useful to Dave or he wouldn't have bothered implemented it, and I can see how it could speed compilation of large projects. I think the ability to hide the implementation (as much as possible) would be of a greater benefit to the D community, but I don't see a reason why we couldn't eventually have both.

So it's more of a case of openning up a present that you think is going to be a cool DVD, and it ends up being a book. It might be a very good book, but you were hoping for a movie. (And I do like to read, too; I'm not illiterate or anything.) ;)

>but I wish to support Walter in some way. As much as I understand the new feature helps speeding up the compiler but it isn't hiding all the code wich comes to be a problem for people wanting close source projects. From the posts I almost thought nobody feels the slow compilition a problem and it is the "people vs Walter". I want to say that this was exactly what I needed, because the compilation speed is a big issue to me. Once I started a thread about this. (Now I am shooting in the dark sorry if I am wrong) It seems that many people are using the build tool (which I've never used but I guess it works this way) or even if they are not they pass all the source files to the compiler. In this case the speed is optimal but if you compile each file separately it becomes like 15 times slower (for my project). And I do it because I have more control over the process this way.
>
>So I just wanted to support Walter and say that this is a very useful feature for me. Thank you, Walter (with much help from Dave Fladebo ;).

I'm not at all against Walter adding this feature to the compiler (and I don't think anyone else really is against it either). I just think he should have called it something else in the announcement. Like "header generator for faster compiling". (Of course, everyone is much better of naming stuff than I am, so that's not a very good suggestion.) Oh, well. What's done is done.

So thanks Walter and Dave. Good job. It's not what I expected, but maybe it's just what D needs. ;)

jcc7