Rats and curses! My cunning underlining of "obdurate" was kindly buggered up my Outlook Express. :(

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c65dmg$310c$2@digitaldaemon.com...
> You see, I told you -->
>
> "Walter" <walter@digitalmars.com> wrote in message news:c65dgk$30pe$1@digitaldaemon.com...
> > To sum up, my esteemed colleague Matthew took Scott's position, and my position was I thought our energies would be better spent designing new functionality than fixing the legacy C windows api.
> >
> > "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c641pr$nhc$1@digitaldaemon.com...
> > > It would indeed. This is an old debate, and I lost to Walter's obdurate
>
>                 ---------  <G>
> > > ability to say no.
> > >
> > > "Scott Egan" <scotte@tpg.com.aux> wrote in message news:c60g07$2ocd$1@digitaldaemon.com...
> > > > I noticed that in std.c.windows.windows the types are all defined as aliases.  Would it be better from a type safety and potential
> > overloading
> > > > point-of-view to use typedefs?
>
>

So if it was done for you would you think about accepting it?

Remembering that it is ultimately what we must all use to natively call Win32.

And I would have thought that building libraries in pure D would be better/eaiser (esp with intellisense).

BTW I think that there is a general over-reliance on C libraries <duck>. Surely the aim should be to make D self standing?



"Walter" <walter@digitalmars.com> wrote in message news:c65dgk$30pe$1@digitaldaemon.com...
> To sum up, my esteemed colleague Matthew took Scott's position, and my position was I thought our energies would be better spent designing new functionality than fixing the legacy C windows api.
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c641pr$nhc$1@digitaldaemon.com...
> > It would indeed. This is an old debate, and I lost to Walter's obdurate ability to say no.
> >
> > "Scott Egan" <scotte@tpg.com.aux> wrote in message news:c60g07$2ocd$1@digitaldaemon.com...
> > > I noticed that in std.c.windows.windows the types are all defined as aliases.  Would it be better from a type safety and potential
> overloading
> > > point-of-view to use typedefs?
> > >
> > >
> >
> >
>
>

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c65dok$314f$1@digitaldaemon.com...
> Rats and curses!

I know what you mean. I set 8 mouse traps in the attic last night, and this morning the peanut butter was licked clean off of each and every one without setting any off. Tonight I'll bring out the pliers to make them "hair trigger".

Nothing keeps one awake at night quite like the sound of gnawing going on right over your head <g>.

Doing this also implies writing new documentation for the Win32 API. That's just way beyond the scope of what we need to do.

"Scott Egan" <scotte@tpg.com.aux> wrote in message news:c65mqo$e79$1@digitaldaemon.com...
> So if it was done for you would you think about accepting it?
>
> Remembering that it is ultimately what we must all use to natively call Win32.
>
> And I would have thought that building libraries in pure D would be better/eaiser (esp with intellisense).
>
> BTW I think that there is a general over-reliance on C libraries <duck>. Surely the aim should be to make D self standing?
>
>
>
> "Walter" <walter@digitalmars.com> wrote in message news:c65dgk$30pe$1@digitaldaemon.com...
> > To sum up, my esteemed colleague Matthew took Scott's position, and my position was I thought our energies would be better spent designing new functionality than fixing the legacy C windows api.
> >
> > "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c641pr$nhc$1@digitaldaemon.com...
> > > It would indeed. This is an old debate, and I lost to Walter's
obdurate
> > > ability to say no.
> > >
> > > "Scott Egan" <scotte@tpg.com.aux> wrote in message news:c60g07$2ocd$1@digitaldaemon.com...
> > > > I noticed that in std.c.windows.windows the types are all defined as aliases.  Would it be better from a type safety and potential
> > overloading
> > > > point-of-view to use typedefs?
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Why does that follow? I don't understand.

"Walter" <walter@digitalmars.com> wrote in message news:c66sgj$2ib1$1@digitaldaemon.com...
> Doing this also implies writing new documentation for the Win32 API. That's just way beyond the scope of what we need to do.
>
> "Scott Egan" <scotte@tpg.com.aux> wrote in message news:c65mqo$e79$1@digitaldaemon.com...
> > So if it was done for you would you think about accepting it?
> >
> > Remembering that it is ultimately what we must all use to natively call Win32.
> >
> > And I would have thought that building libraries in pure D would be better/eaiser (esp with intellisense).
> >
> > BTW I think that there is a general over-reliance on C libraries <duck>. Surely the aim should be to make D self standing?
> >
> >
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:c65dgk$30pe$1@digitaldaemon.com...
> > > To sum up, my esteemed colleague Matthew took Scott's position, and my position was I thought our energies would be better spent designing new functionality than fixing the legacy C windows api.
> > >
> > > "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c641pr$nhc$1@digitaldaemon.com...
> > > > It would indeed. This is an old debate, and I lost to Walter's
> obdurate
> > > > ability to say no.
> > > >
> > > > "Scott Egan" <scotte@tpg.com.aux> wrote in message news:c60g07$2ocd$1@digitaldaemon.com...
> > > > > I noticed that in std.c.windows.windows the types are all defined as aliases.  Would it be better from a type safety and potential
> > > overloading
> > > > > point-of-view to use typedefs?
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

I get uncomfortable when I see a prototype for a function that doesn't match what the documentation says. To me, that screams "bug".

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c66sm4$2ih0$1@digitaldaemon.com...
> Why does that follow? I don't understand.
>
> "Walter" <walter@digitalmars.com> wrote in message news:c66sgj$2ib1$1@digitaldaemon.com...
> > Doing this also implies writing new documentation for the Win32 API.
That's
> > just way beyond the scope of what we need to do.
> >
> > "Scott Egan" <scotte@tpg.com.aux> wrote in message news:c65mqo$e79$1@digitaldaemon.com...
> > > So if it was done for you would you think about accepting it?
> > >
> > > Remembering that it is ultimately what we must all use to natively
call
> > > Win32.
> > >
> > > And I would have thought that building libraries in pure D would be better/eaiser (esp with intellisense).
> > >
> > > BTW I think that there is a general over-reliance on C libraries
<duck>.
> > > Surely the aim should be to make D self standing?
> > >
> > >
> > >
> > > "Walter" <walter@digitalmars.com> wrote in message news:c65dgk$30pe$1@digitaldaemon.com...
> > > > To sum up, my esteemed colleague Matthew took Scott's position, and
my
> > > > position was I thought our energies would be better spent designing
new
> > > > functionality than fixing the legacy C windows api.
> > > >
> > > > "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c641pr$nhc$1@digitaldaemon.com...
> > > > > It would indeed. This is an old debate, and I lost to Walter's
> > obdurate
> > > > > ability to say no.
> > > > >
> > > > > "Scott Egan" <scotte@tpg.com.aux> wrote in message news:c60g07$2ocd$1@digitaldaemon.com...
> > > > > > I noticed that in std.c.windows.windows the types are all
defined as
> > > > > > aliases.  Would it be better from a type safety and potential
> > > > overloading
> > > > > > point-of-view to use typedefs?
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

That's not what I'm talking about.

In std.windows.registry I defined HKEY as a typedef, rather than an alias. This
means that I cannot pass a HKEY to, say, CloseHandle(), and no-one can pass a
HANDLE to RegCreateKey().

As I've said many times, I totally fail to see any flaw in this approach, and I've not yet experienced one in practice.

"Walter" <walter@digitalmars.com> wrote in message news:c67i3b$kkk$1@digitaldaemon.com...
> I get uncomfortable when I see a prototype for a function that doesn't match what the documentation says. To me, that screams "bug".
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c66sm4$2ih0$1@digitaldaemon.com...
> > Why does that follow? I don't understand.
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:c66sgj$2ib1$1@digitaldaemon.com...
> > > Doing this also implies writing new documentation for the Win32 API.
> That's
> > > just way beyond the scope of what we need to do.
> > >
> > > "Scott Egan" <scotte@tpg.com.aux> wrote in message news:c65mqo$e79$1@digitaldaemon.com...
> > > > So if it was done for you would you think about accepting it?
> > > >
> > > > Remembering that it is ultimately what we must all use to natively
> call
> > > > Win32.
> > > >
> > > > And I would have thought that building libraries in pure D would be better/eaiser (esp with intellisense).
> > > >
> > > > BTW I think that there is a general over-reliance on C libraries
> <duck>.
> > > > Surely the aim should be to make D self standing?
> > > >
> > > >
> > > >
> > > > "Walter" <walter@digitalmars.com> wrote in message news:c65dgk$30pe$1@digitaldaemon.com...
> > > > > To sum up, my esteemed colleague Matthew took Scott's position, and
> my
> > > > > position was I thought our energies would be better spent designing
> new
> > > > > functionality than fixing the legacy C windows api.
> > > > >
> > > > > "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c641pr$nhc$1@digitaldaemon.com...
> > > > > > It would indeed. This is an old debate, and I lost to Walter's
> > > obdurate
> > > > > > ability to say no.
> > > > > >
> > > > > > "Scott Egan" <scotte@tpg.com.aux> wrote in message news:c60g07$2ocd$1@digitaldaemon.com...
> > > > > > > I noticed that in std.c.windows.windows the types are all
> defined as
> > > > > > > aliases.  Would it be better from a type safety and potential
> > > > > overloading
> > > > > > > point-of-view to use typedefs?
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

I've encountered enough inconsistencies in windows code to make making them typedefs a nuisance. The documentation problem comes in when inout and out parameters are folded in.

"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c67jas$mgd$1@digitaldaemon.com...
> That's not what I'm talking about.
>
> In std.windows.registry I defined HKEY as a typedef, rather than an alias.
This
> means that I cannot pass a HKEY to, say, CloseHandle(), and no-one can
pass a
> HANDLE to RegCreateKey().
>
> As I've said many times, I totally fail to see any flaw in this approach,
and
> I've not yet experienced one in practice.
>
> "Walter" <walter@digitalmars.com> wrote in message news:c67i3b$kkk$1@digitaldaemon.com...
> > I get uncomfortable when I see a prototype for a function that doesn't
match
> > what the documentation says. To me, that screams "bug".
> >
> > "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c66sm4$2ih0$1@digitaldaemon.com...
> > > Why does that follow? I don't understand.
> > >
> > > "Walter" <walter@digitalmars.com> wrote in message news:c66sgj$2ib1$1@digitaldaemon.com...
> > > > Doing this also implies writing new documentation for the Win32 API.
> > That's
> > > > just way beyond the scope of what we need to do.
> > > >
> > > > "Scott Egan" <scotte@tpg.com.aux> wrote in message news:c65mqo$e79$1@digitaldaemon.com...
> > > > > So if it was done for you would you think about accepting it?
> > > > >
> > > > > Remembering that it is ultimately what we must all use to natively
> > call
> > > > > Win32.
> > > > >
> > > > > And I would have thought that building libraries in pure D would
be
> > > > > better/eaiser (esp with intellisense).
> > > > >
> > > > > BTW I think that there is a general over-reliance on C libraries
> > <duck>.
> > > > > Surely the aim should be to make D self standing?
> > > > >
> > > > >
> > > > >
> > > > > "Walter" <walter@digitalmars.com> wrote in message news:c65dgk$30pe$1@digitaldaemon.com...
> > > > > > To sum up, my esteemed colleague Matthew took Scott's position,
and
> > my
> > > > > > position was I thought our energies would be better spent
designing
> > new
> > > > > > functionality than fixing the legacy C windows api.
> > > > > >
> > > > > > "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c641pr$nhc$1@digitaldaemon.com...
> > > > > > > It would indeed. This is an old debate, and I lost to Walter's
> > > > obdurate
> > > > > > > ability to say no.
> > > > > > >
> > > > > > > "Scott Egan" <scotte@tpg.com.aux> wrote in message news:c60g07$2ocd$1@digitaldaemon.com...
> > > > > > > > I noticed that in std.c.windows.windows the types are all
> > defined as
> > > > > > > > aliases.  Would it be better from a type safety and
potential
> > > > > > overloading
> > > > > > > > point-of-view to use typedefs?
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Your design is good.  But what if there is some API that Microsoft documented to work like this:
	VOID DoStuffWithKey(HANDLE);
then you are stuck with having to fix Microsoft's broken design...your code must use the Right definition, which is different than the one that is in the docs.

Personally, I'm supportive of you if you want to track down all of these problems and fix the Windows API.  But I agree with Walter that it's probably a lot of work with little real gain :(  More power to ya, though.

Russ

Matthew wrote:
> That's not what I'm talking about.
> 
> In std.windows.registry I defined HKEY as a typedef, rather than an alias. This
> means that I cannot pass a HKEY to, say, CloseHandle(), and no-one can pass a
> HANDLE to RegCreateKey().
> 
> As I've said many times, I totally fail to see any flaw in this approach, and
> I've not yet experienced one in practice.
> 
> "Walter" <walter@digitalmars.com> wrote in message
> news:c67i3b$kkk$1@digitaldaemon.com...
> 
>>I get uncomfortable when I see a prototype for a function that doesn't match
>>what the documentation says. To me, that screams "bug".
>>
>>"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message
>>news:c66sm4$2ih0$1@digitaldaemon.com...
>>
>>>Why does that follow? I don't understand.
>>>
>>>"Walter" <walter@digitalmars.com> wrote in message
>>>news:c66sgj$2ib1$1@digitaldaemon.com...
>>>
>>>>Doing this also implies writing new documentation for the Win32 API.
>>
>>That's
>>
>>>>just way beyond the scope of what we need to do.
>>>>
>>>>"Scott Egan" <scotte@tpg.com.aux> wrote in message
>>>>news:c65mqo$e79$1@digitaldaemon.com...
>>>>
>>>>>So if it was done for you would you think about accepting it?
>>>>>
>>>>>Remembering that it is ultimately what we must all use to natively
>>
>>call
>>
>>>>>Win32.
>>>>>
>>>>>And I would have thought that building libraries in pure D would be
>>>>>better/eaiser (esp with intellisense).
>>>>>
>>>>>BTW I think that there is a general over-reliance on C libraries
>>
>><duck>.
>>
>>>>>Surely the aim should be to make D self standing?
>>>>>
>>>>>
>>>>>
>>>>>"Walter" <walter@digitalmars.com> wrote in message
>>>>>news:c65dgk$30pe$1@digitaldaemon.com...
>>>>>
>>>>>>To sum up, my esteemed colleague Matthew took Scott's position, and
>>
>>my
>>
>>>>>>position was I thought our energies would be better spent designing
>>
>>new
>>
>>>>>>functionality than fixing the legacy C windows api.
>>>>>>
>>>>>>"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message
>>>>>>news:c641pr$nhc$1@digitaldaemon.com...
>>>>>>
>>>>>>>It would indeed. This is an old debate, and I lost to Walter's
>>>>
>>>>obdurate
>>>>
>>>>>>>ability to say no.
>>>>>>>
>>>>>>>"Scott Egan" <scotte@tpg.com.aux> wrote in message
>>>>>>>news:c60g07$2ocd$1@digitaldaemon.com...
>>>>>>>
>>>>>>>>I noticed that in std.c.windows.windows the types are all
>>
>>defined as
>>
>>>>>>>>aliases.  Would it be better from a type safety and potential
>>>>>>
>>>>>>overloading
>>>>>>
>>>>>>>>point-of-view to use typedefs?

> Your design is good.  But what if there is some API that Microsoft
> documented to work like this:
> VOID DoStuffWithKey(HANDLE);
> then you are stuck with having to fix Microsoft's broken design...your
> code must use the Right definition, which is different than the one that
> is in the docs.

This is only an issue with an automated .h=>.d tool. And any decent implementation of that could keep bad_function lists, in which a map of the arg # and good/bad types could be recorded and acted upon.

> Personally, I'm supportive of you if you want to track down all of these problems and fix the Windows API.  But I agree with Walter that it's probably a lot of work with little real gain :(  More power to ya, though.

If it's all done by one person, in one go, of course. But it's really as simple as making HKEY, HFONT etc. typedefs, and then going from there. As I've said over and over when this has been discussed, doing this has caused me precisely ZERO problems or extra work thus far.

>
> Russ
>
> Matthew wrote:
> > That's not what I'm talking about.
> >
> > In std.windows.registry I defined HKEY as a typedef, rather than an alias.
This
> > means that I cannot pass a HKEY to, say, CloseHandle(), and no-one can pass a
> > HANDLE to RegCreateKey().
> >
> > As I've said many times, I totally fail to see any flaw in this approach, and I've not yet experienced one in practice.
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:c67i3b$kkk$1@digitaldaemon.com...
> >
> >>I get uncomfortable when I see a prototype for a function that doesn't match what the documentation says. To me, that screams "bug".
> >>
> >>"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c66sm4$2ih0$1@digitaldaemon.com...
> >>
> >>>Why does that follow? I don't understand.
> >>>
> >>>"Walter" <walter@digitalmars.com> wrote in message news:c66sgj$2ib1$1@digitaldaemon.com...
> >>>
> >>>>Doing this also implies writing new documentation for the Win32 API.
> >>
> >>That's
> >>
> >>>>just way beyond the scope of what we need to do.
> >>>>
> >>>>"Scott Egan" <scotte@tpg.com.aux> wrote in message news:c65mqo$e79$1@digitaldaemon.com...
> >>>>
> >>>>>So if it was done for you would you think about accepting it?
> >>>>>
> >>>>>Remembering that it is ultimately what we must all use to natively
> >>
> >>call
> >>
> >>>>>Win32.
> >>>>>
> >>>>>And I would have thought that building libraries in pure D would be better/eaiser (esp with intellisense).
> >>>>>
> >>>>>BTW I think that there is a general over-reliance on C libraries
> >>
> >><duck>.
> >>
> >>>>>Surely the aim should be to make D self standing?
> >>>>>
> >>>>>
> >>>>>
> >>>>>"Walter" <walter@digitalmars.com> wrote in message news:c65dgk$30pe$1@digitaldaemon.com...
> >>>>>
> >>>>>>To sum up, my esteemed colleague Matthew took Scott's position, and
> >>
> >>my
> >>
> >>>>>>position was I thought our energies would be better spent designing
> >>
> >>new
> >>
> >>>>>>functionality than fixing the legacy C windows api.
> >>>>>>
> >>>>>>"Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c641pr$nhc$1@digitaldaemon.com...
> >>>>>>
> >>>>>>>It would indeed. This is an old debate, and I lost to Walter's
> >>>>
> >>>>obdurate
> >>>>
> >>>>>>>ability to say no.
> >>>>>>>
> >>>>>>>"Scott Egan" <scotte@tpg.com.aux> wrote in message news:c60g07$2ocd$1@digitaldaemon.com...
> >>>>>>>
> >>>>>>>>I noticed that in std.c.windows.windows the types are all
> >>
> >>defined as
> >>
> >>>>>>>>aliases.  Would it be better from a type safety and potential
> >>>>>>
> >>>>>>overloading
> >>>>>>
> >>>>>>>>point-of-view to use typedefs?
>