Don Clugston wrote:
<snip>
>> (a) If the whole point of a module is to import other modules, then
>> obviously the imports have to be public.
>> (b) If qwert.h doesn't include yuiop.h, but yuiop.d is required for
>> qwert.d to compile, then the import should be private.
>> (c) This leaves the general case where a C header includes another.
>>
>> Should we make imports of kind (c) public or private?  Moreover, should
>> we declare (b) and (c) imports using "private import" or simply "import"?
> 
> I think (c) should be private, except in a few rare cases where they are 'top-level' modules that do nothing except publically import other modules.

By (c), I actually meant that which doesn't fit under (a) or (b).  I can't think of any instances in which a module does nothing but imports other modules but that isn't the whole point of the module.

<snip>
>> We've less than 30 days to get it done and dusted if we're going to
>> submit a full translation for DMD 1.0.  Even better would be if it can
>> be got done by the time I go back to my immediate family for Christmas
>> around the 20th.  So come on guys!

Good to know you're still here.  You used to be one of the most active contributors to this project.  Hope you really are back!

Stewart.

Stewart Gordon wrote:
> Don Clugston wrote:
> <snip>
>>> (a) If the whole point of a module is to import other modules, then
>>> obviously the imports have to be public.
>>> (b) If qwert.h doesn't include yuiop.h, but yuiop.d is required for
>>> qwert.d to compile, then the import should be private.
>>> (c) This leaves the general case where a C header includes another.
>>>
>>> Should we make imports of kind (c) public or private?  Moreover, should
>>> we declare (b) and (c) imports using "private import" or simply "import"?
>>
>> I think (c) should be private, except in a few rare cases where they are 'top-level' modules that do nothing except publically import other modules.
> 
> By (c), I actually meant that which doesn't fit under (a) or (b).  I can't think of any instances in which a module does nothing but imports other modules but that isn't the whole point of the module.

I think I created windows.core, which does that, but it's probably unique. I think we should try to eliminate all cases of (c), turning them into (a) or (b). What are the case (c)'s at the moment?

> <snip>
>>> We've less than 30 days to get it done and dusted if we're going to
>>> submit a full translation for DMD 1.0.  Even better would be if it can
>>> be got done by the time I go back to my immediate family for Christmas
>>> around the 20th.  So come on guys!
> 
> Good to know you're still here.  You used to be one of the most active contributors to this project.  Hope you really are back!

I doubt I'll contribute much more to the Windows API project anytime before D 1.0, I'm too tied up in another D project.

A couple of suggestions, though:
* vfw is an obselete, buggy technology, and the MinGW header is a disaster area. I think we should just drop it.
* Some of the other MinGW header, like zmouse, are so incomplete there're probably not worth including.
* We don't need windowsx, either, it's just for C programmers without OO.

Don Clugston wrote:
> Stewart Gordon wrote:
>> Don Clugston wrote:
>> <snip>
>>>> (a) If the whole point of a module is to import other modules, then obviously the imports have to be public.
>>>> (b) If qwert.h doesn't include yuiop.h, but yuiop.d is required for qwert.d to compile, then the import should be private.
>>>> (c) This leaves the general case where a C header includes another.
<snip>
> I think I created windows.core, which does that, but it's probably unique. I think we should try to eliminate all cases of (c), turning them into (a) or (b).

The cases (a), (b) and (c) are from the POV of the C headers.  That was about what each case should become in the D code.  It would make no sense to change anything to (b), because in D you can't use a symbol from another module without importing it.

> What are the case (c)'s at the moment?

See for yourself.  Grep the MinGW headers for "#include", and then cross off those headers that have no content but #include directives.

<snip>
> I doubt I'll contribute much more to the Windows API project anytime before D 1.0, I'm too tied up in another D project.

I know what you mean - I get tied up in different D projects from time to time too.  Thank you for telling us - though it would've been nice to have known sooner.

> A couple of suggestions, though:
> * vfw is an obselete, buggy technology, and the MinGW header is a disaster area. I think we should just drop it.

I don't know enough about vfw to give any first-hand opinion, but on the basis of what you say, if nobody disagrees then maybe we should get rid of it indeed.

> * Some of the other MinGW header, like zmouse, are so incomplete there're probably not worth including.

Indeed, zmouse does nothing but defines constants that are already defined elsewhere.

> * We don't need windowsx, either, it's just for C programmers without OO.

I'm not sure what I think to this.  It defines macros for manipulating the older Windows controls, just as commctrl does for the newer ones. But they aren't documented in my win32.hlp.

Stewart.

Stewart Gordon wrote:
> Don Clugston wrote:
>> Stewart Gordon wrote:
>>> Don Clugston wrote:
>>> <snip>
>>>>> (a) If the whole point of a module is to import other modules, then obviously the imports have to be public.
>>>>> (b) If qwert.h doesn't include yuiop.h, but yuiop.d is required for qwert.d to compile, then the import should be private.
>>>>> (c) This leaves the general case where a C header includes another.
> <snip>
>> I think I created windows.core, which does that, but it's probably unique. I think we should try to eliminate all cases of (c), turning them into (a) or (b).
> 
> The cases (a), (b) and (c) are from the POV of the C headers.  That was about what each case should become in the D code.  It would make no sense to change anything to (b), because in D you can't use a symbol from another module without importing it.

There are many cases where the SDK docs say "this is in xxx.h, but do not #include xxx.h directly. Instead, use yyy.h which includes xxx.h".
Sometimes it turns out that yyy is including zzz.h which is including xxx.h.
In this situation, I think that zzz should privately import xxx, and yyy should publicly import both xxx and zzz.
That is, the only instances of public imports should be with modules intended to be directly imported by the user.

>> What are the case (c)'s at the moment?
> 
> See for yourself.  Grep the MinGW headers for "#include", and then cross off those headers that have no content but #include directives.
> 
> <snip>
>> I doubt I'll contribute much more to the Windows API project anytime before D 1.0, I'm too tied up in another D project.
> 
> I know what you mean - I get tied up in different D projects from time to time too.  Thank you for telling us - though it would've been nice to have known sooner.
> 
>> A couple of suggestions, though:
>> * vfw is an obselete, buggy technology, and the MinGW header is a disaster area. I think we should just drop it.
> 
> I don't know enough about vfw to give any first-hand opinion, but on the basis of what you say, if nobody disagrees then maybe we should get rid of it indeed.
> 
>> * Some of the other MinGW header, like zmouse, are so incomplete there're probably not worth including.
> 
> Indeed, zmouse does nothing but defines constants that are already defined elsewhere.
> 
>> * We don't need windowsx, either, it's just for C programmers without OO.
> 
> I'm not sure what I think to this.  It defines macros for manipulating the older Windows controls, just as commctrl does for the newer ones. But they aren't documented in my win32.hlp.

It's ancient. It was around in the Windows 3.0 days, maybe even older. They just kept including it for backwards compatibility.
It's probably best to think of windowsx.h as 'framework code', like MFC, rather than part of the WinAPI itself.
Arguably we want a D equivalent of it, but that would be very different to a port.

On the basis of consensus and the lack thereof, I've made a few small changes to the instructions.  Please see the wiki page.

Stewart.