I was just wondering if anyone could tell me why we do not use typedef rather than alias for such things as HKEY?

It seems to me this would be a simple and elegant tightening of the Win32 type-system.

Matthew

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bh1j1d$t44$1@digitaldaemon.com...
> I was just wondering if anyone could tell me why we do not use typedef rather than alias for such things as HKEY?
>
> It seems to me this would be a simple and elegant tightening of the Win32 type-system.

One of my early thoughts was also to clean up the win32 type system. Unfortunately, most code plays fast and loose with using C typedefs mixed in with the underlying types. Microsoft's own sample code is woefully inconsistent about it. It's so much easier to just use alias for them and not worry about it. Save the clean designs for doing something new, not legacy API's.

> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bh1j1d$t44$1@digitaldaemon.com...
> > I was just wondering if anyone could tell me why we do not use typedef rather than alias for such things as HKEY?
> >
> > It seems to me this would be a simple and elegant tightening of the
Win32
> > type-system.
>
> One of my early thoughts was also to clean up the win32 type system. Unfortunately, most code plays fast and loose with using C typedefs mixed
in
> with the underlying types. Microsoft's own sample code is woefully inconsistent about it. It's so much easier to just use alias for them and not worry about it. Save the clean designs for doing something new, not legacy API's.


This doesn't make any sense to me. Since all the definitions are, by definition, in D, why does it matter what the existing definitions are.

Having said that, I've not tried it, so if you can give me a single simple example I'll pull my head in. ;)

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bh1m0l$vq8$1@digitaldaemon.com...
> > "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bh1j1d$t44$1@digitaldaemon.com...
> > > I was just wondering if anyone could tell me why we do not use typedef
> > > rather than alias for such things as HKEY?
> > > It seems to me this would be a simple and elegant tightening of the
> Win32
> > > type-system.
> > One of my early thoughts was also to clean up the win32 type system. Unfortunately, most code plays fast and loose with using C typedefs
mixed
> in
> > with the underlying types. Microsoft's own sample code is woefully inconsistent about it. It's so much easier to just use alias for them
and
> > not worry about it. Save the clean designs for doing something new, not legacy API's.
> This doesn't make any sense to me. Since all the definitions are, by definition, in D, why does it matter what the existing definitions are.

Because to call them, you'll need to look at example code. The example code is inconsistent.

> Having said that, I've not tried it, so if you can give me a single simple example I'll pull my head in. ;)

Try explaining the elegant difference between GUID, UUID, IID, CLSID, FMTID? <g>

Another I ran across repeatedly are the multiple ways of doing wchar_t's. There seems to be half-a-dozen different typedefs for those in the Microsoft headers, with overlapping usage. I ran into this a lot doing the javascript implementation. LPOLESTR vs LPWSTR anyone?

Another is the constant typedefs for LPxxxxx, and then just using xxxxx* anyway.

How about ULONG vs DWORD? PBOOL vs LPBOOL? typedef void VOID? all the
DECLARE_HANDLE() macros?

I can see the merit in some of what you say. LOL.

Nonetheless, if we have people who are across these issues (and I am
comfortable with every one of your examples - though I'm not volunteering
for the task!!), then I still fail to see why (i) it cannot be done, and
(ii) it would not be significantly advantageous.

I seriously suggest everyone give this some serious thought. Let's have some votes on it.

For: 1
Against: 1

"Walter" <walter@digitalmars.com> wrote in message news:bh202k$18mj$1@digitaldaemon.com...
>
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bh1m0l$vq8$1@digitaldaemon.com...
> > > "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bh1j1d$t44$1@digitaldaemon.com...
> > > > I was just wondering if anyone could tell me why we do not use
typedef
> > > > rather than alias for such things as HKEY?
> > > > It seems to me this would be a simple and elegant tightening of the
> > Win32
> > > > type-system.
> > > One of my early thoughts was also to clean up the win32 type system. Unfortunately, most code plays fast and loose with using C typedefs
> mixed
> > in
> > > with the underlying types. Microsoft's own sample code is woefully inconsistent about it. It's so much easier to just use alias for them
> and
> > > not worry about it. Save the clean designs for doing something new,
not
> > > legacy API's.
> > This doesn't make any sense to me. Since all the definitions are, by definition, in D, why does it matter what the existing definitions are.
>
> Because to call them, you'll need to look at example code. The example
code
> is inconsistent.
>
> > Having said that, I've not tried it, so if you can give me a single
simple
> > example I'll pull my head in. ;)
>
> Try explaining the elegant difference between GUID, UUID, IID, CLSID,
FMTID?
> <g>
>
> Another I ran across repeatedly are the multiple ways of doing wchar_t's. There seems to be half-a-dozen different typedefs for those in the
Microsoft
> headers, with overlapping usage. I ran into this a lot doing the
javascript
> implementation. LPOLESTR vs LPWSTR anyone?
>
> Another is the constant typedefs for LPxxxxx, and then just using xxxxx* anyway.
>
> How about ULONG vs DWORD? PBOOL vs LPBOOL? typedef void VOID? all the
> DECLARE_HANDLE() macros?
>
>

If someone was going to try this, I suggest at least start out using alias's. Then try a couple typedef's, and see what happens <g>. I predict it won't be long until things go back to alias. You can't realistically retrofit type safety on a system that's been aggregating new aliases for 15 years. Cleaning up the Windows API is something way beyond the scope of D.

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bh20hh$18v0$1@digitaldaemon.com...
> I can see the merit in some of what you say. LOL.
>
> Nonetheless, if we have people who are across these issues (and I am
> comfortable with every one of your examples - though I'm not volunteering
> for the task!!), then I still fail to see why (i) it cannot be done, and
> (ii) it would not be significantly advantageous.
>
> I seriously suggest everyone give this some serious thought. Let's have
some
> votes on it.
>
> For: 1
> Against: 1
>
> "Walter" <walter@digitalmars.com> wrote in message news:bh202k$18mj$1@digitaldaemon.com...
> >
> > "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bh1m0l$vq8$1@digitaldaemon.com...
> > > > "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bh1j1d$t44$1@digitaldaemon.com...
> > > > > I was just wondering if anyone could tell me why we do not use
> typedef
> > > > > rather than alias for such things as HKEY?
> > > > > It seems to me this would be a simple and elegant tightening of
the
> > > Win32
> > > > > type-system.
> > > > One of my early thoughts was also to clean up the win32 type system. Unfortunately, most code plays fast and loose with using C typedefs
> > mixed
> > > in
> > > > with the underlying types. Microsoft's own sample code is woefully inconsistent about it. It's so much easier to just use alias for
them
> > and
> > > > not worry about it. Save the clean designs for doing something new,
> not
> > > > legacy API's.
> > > This doesn't make any sense to me. Since all the definitions are, by definition, in D, why does it matter what the existing definitions
are.
> >
> > Because to call them, you'll need to look at example code. The example
> code
> > is inconsistent.
> >
> > > Having said that, I've not tried it, so if you can give me a single
> simple
> > > example I'll pull my head in. ;)
> >
> > Try explaining the elegant difference between GUID, UUID, IID, CLSID,
> FMTID?
> > <g>
> >
> > Another I ran across repeatedly are the multiple ways of doing
wchar_t's.
> > There seems to be half-a-dozen different typedefs for those in the
> Microsoft
> > headers, with overlapping usage. I ran into this a lot doing the
> javascript
> > implementation. LPOLESTR vs LPWSTR anyone?
> >
> > Another is the constant typedefs for LPxxxxx, and then just using xxxxx* anyway.
> >
> > How about ULONG vs DWORD? PBOOL vs LPBOOL? typedef void VOID? all the
> > DECLARE_HANDLE() macros?
> >
> >
>
>

I'm still unconvinced, so I guess I'll just have to break my hubris on the rocks of experience, and try it myself.

Watch this space ...

"Walter" <walter@digitalmars.com> wrote in message news:bh21tm$1a47$1@digitaldaemon.com...
> If someone was going to try this, I suggest at least start out using alias's. Then try a couple typedef's, and see what happens <g>. I predict
it
> won't be long until things go back to alias. You can't realistically retrofit type safety on a system that's been aggregating new aliases for
15
> years. Cleaning up the Windows API is something way beyond the scope of D.
>
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bh20hh$18v0$1@digitaldaemon.com...
> > I can see the merit in some of what you say. LOL.
> >
> > Nonetheless, if we have people who are across these issues (and I am comfortable with every one of your examples - though I'm not
volunteering
> > for the task!!), then I still fail to see why (i) it cannot be done, and
> > (ii) it would not be significantly advantageous.
> >
> > I seriously suggest everyone give this some serious thought. Let's have
> some
> > votes on it.
> >
> > For: 1
> > Against: 1
> >
> > "Walter" <walter@digitalmars.com> wrote in message news:bh202k$18mj$1@digitaldaemon.com...
> > >
> > > "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bh1m0l$vq8$1@digitaldaemon.com...
> > > > > "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bh1j1d$t44$1@digitaldaemon.com...
> > > > > > I was just wondering if anyone could tell me why we do not use
> > typedef
> > > > > > rather than alias for such things as HKEY?
> > > > > > It seems to me this would be a simple and elegant tightening of
> the
> > > > Win32
> > > > > > type-system.
> > > > > One of my early thoughts was also to clean up the win32 type
system.
> > > > > Unfortunately, most code plays fast and loose with using C
typedefs
> > > mixed
> > > > in
> > > > > with the underlying types. Microsoft's own sample code is woefully inconsistent about it. It's so much easier to just use alias for
> them
> > > and
> > > > > not worry about it. Save the clean designs for doing something
new,
> > not
> > > > > legacy API's.
> > > > This doesn't make any sense to me. Since all the definitions are, by definition, in D, why does it matter what the existing definitions
> are.
> > >
> > > Because to call them, you'll need to look at example code. The example
> > code
> > > is inconsistent.
> > >
> > > > Having said that, I've not tried it, so if you can give me a single
> > simple
> > > > example I'll pull my head in. ;)
> > >
> > > Try explaining the elegant difference between GUID, UUID, IID, CLSID,
> > FMTID?
> > > <g>
> > >
> > > Another I ran across repeatedly are the multiple ways of doing
> wchar_t's.
> > > There seems to be half-a-dozen different typedefs for those in the
> > Microsoft
> > > headers, with overlapping usage. I ran into this a lot doing the
> > javascript
> > > implementation. LPOLESTR vs LPWSTR anyone?
> > >
> > > Another is the constant typedefs for LPxxxxx, and then just using
xxxxx*
> > > anyway.
> > >
> > > How about ULONG vs DWORD? PBOOL vs LPBOOL? typedef void VOID? all the
> > > DECLARE_HANDLE() macros?
> > >
> > >
> >
> >
>
>

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bh20hh$18v0$1@digitaldaemon.com...
> I can see the merit in some of what you say. LOL.
>
> Nonetheless, if we have people who are across these issues (and I am
> comfortable with every one of your examples - though I'm not volunteering
> for the task!!), then I still fail to see why (i) it cannot be done, and
> (ii) it would not be significantly advantageous.
>
> I seriously suggest everyone give this some serious thought. Let's have
some
> votes on it.
>
> For: 1
> Against: 1

against : 2

before you start voting for I suggest you try porting some windows header
and use them .....
then you'll see why alias is better (for now) see below.
>
> "Walter" <walter@digitalmars.com> wrote in message
> >
> > Try explaining the elegant difference between GUID, UUID, IID, CLSID,
> FMTID?
> > <g>
nice example ...

> >
> > Another I ran across repeatedly are the multiple ways of doing
wchar_t's.
> > There seems to be half-a-dozen different typedefs for those in the
> Microsoft
> > headers, with overlapping usage. I ran into this a lot doing the
> javascript
> > implementation. LPOLESTR vs LPWSTR anyone?

> > Another is the constant typedefs for LPxxxxx, and then just using xxxxx* anyway.

> > How about ULONG vs DWORD? PBOOL vs LPBOOL? typedef void VOID? all the
> > DECLARE_HANDLE() macros?

most of these are legacy from the win3.xx days when windows run in realmode,
286 protected mode and 386 protected mode, so near and far pointers where
needed
PBOOL => int near *  LPBOOL => int far *

ULONG and DWORD are the same on x86 arch's but are they on Alpha or Mips NT ?

LPOLESTR is a string that OLE uses (originally I believe this was `char
far*`)
LPWSTR is a wide char string not sure if that has to be 16bit or if it might
be 32 bit in later MS OS's

the question is should the D windows modules be kept inline with the MS C interface or should we define a new way to program on win32 platfroms. I think most ppl who use win32 will say keep it MS like, it might be a little rubbish, and polutes the global name space with 1,000,000's of type aliases but means that you can port C code to D without having to change vast sections of code.

if someone was willing to put the effort in then maybe I'd say have 2
windows modules
windows.d (imports what you need D style as much as pos) window_compat.d
import a huge amount of aliases for ease of programming.

just try using typedefs for Handles and their possible uses HMODULE, HDC,
HBRUSH etc
as an example think of using
typedef void * HANDLE;
typedef HANDLE HGDI_OBJECT;
typedef HGDI_OBJECT HBRUSH;
typedef HGDI_OBJECT HBITMAP;

HBRUSH CreateSolidBrush( ... ); O.K.
HGDI_OBJECT SelectObject( HDC, HGDI_OBJECT );

so every call to SelectObject requires a cast.
it might be nice if you could alias on params
i.e.
alias HBRUSH SelectObject( HDC, HBRUSH ) SelectObject;
alias HBITMAP SelectObject( HDC, HBITMAP ) SelectObject;

> Another is the constant typedefs for LPxxxxx, and then just using xxxxx* anyway.
>
> How about ULONG vs DWORD? PBOOL vs LPBOOL? typedef void VOID? all the
> DECLARE_HANDLE() macros?

One of my favourites is HINSTANCE vs HMODULE; both things specify exactly the same entity both in meaning and in underlying type, you sometimes need to pass values you can only acquire as HINSTANCEs to functions expecting HMODULEs, et cetera et cetera.

I'm relatively sure that "cleaning up" this syntax would actually make the situation far worse than it currently is.

-fg

Sounds like a challenge. I get your point, but the GDI handle thing can be handled by a little fake polymorphism, surely?

Anyway, I understand that it's a practical challenge, and the only way I'll win over anyone is by doing it. Alas, it's going to be a couple of months before I'll be doing some serious D-programming, but I will certainly try out my approach at that time and report in (with my tail between my legs, no doubt).


"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bh2pd0$2458$1@digitaldaemon.com...
>
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bh20hh$18v0$1@digitaldaemon.com...
> > I can see the merit in some of what you say. LOL.
> >
> > Nonetheless, if we have people who are across these issues (and I am comfortable with every one of your examples - though I'm not
volunteering
> > for the task!!), then I still fail to see why (i) it cannot be done, and
> > (ii) it would not be significantly advantageous.
> >
> > I seriously suggest everyone give this some serious thought. Let's have
> some
> > votes on it.
> >
> > For: 1
> > Against: 1
>
> against : 2
>
> before you start voting for I suggest you try porting some windows header
> and use them .....
> then you'll see why alias is better (for now) see below.
> >
> > "Walter" <walter@digitalmars.com> wrote in message
> > >
> > > Try explaining the elegant difference between GUID, UUID, IID, CLSID,
> > FMTID?
> > > <g>
> nice example ...
>
> > >
> > > Another I ran across repeatedly are the multiple ways of doing
> wchar_t's.
> > > There seems to be half-a-dozen different typedefs for those in the
> > Microsoft
> > > headers, with overlapping usage. I ran into this a lot doing the
> > javascript
> > > implementation. LPOLESTR vs LPWSTR anyone?
>
> > > Another is the constant typedefs for LPxxxxx, and then just using
xxxxx*
> > > anyway.
>
> > > How about ULONG vs DWORD? PBOOL vs LPBOOL? typedef void VOID? all the
> > > DECLARE_HANDLE() macros?
>
> most of these are legacy from the win3.xx days when windows run in
realmode,
> 286 protected mode and 386 protected mode, so near and far pointers where
> needed
> PBOOL => int near *  LPBOOL => int far *
>
> ULONG and DWORD are the same on x86 arch's but are they on Alpha or Mips
NT
> ?
>
> LPOLESTR is a string that OLE uses (originally I believe this was `char
> far*`)
> LPWSTR is a wide char string not sure if that has to be 16bit or if it
might
> be 32 bit in later MS OS's
>
> the question is should the D windows modules be kept inline with the MS C interface or should we define a new way to program on win32 platfroms. I think most ppl who use win32 will say keep it MS like, it might be a
little
> rubbish, and polutes the global name space with 1,000,000's of type
aliases
> but means that you can port C code to D without having to change vast sections of code.
>
> if someone was willing to put the effort in then maybe I'd say have 2
> windows modules
> windows.d (imports what you need D style as much as pos) window_compat.d
> import a huge amount of aliases for ease of programming.
>
> just try using typedefs for Handles and their possible uses HMODULE, HDC,
> HBRUSH etc
> as an example think of using
> typedef void * HANDLE;
> typedef HANDLE HGDI_OBJECT;
> typedef HGDI_OBJECT HBRUSH;
> typedef HGDI_OBJECT HBITMAP;
>
> HBRUSH CreateSolidBrush( ... ); O.K.
> HGDI_OBJECT SelectObject( HDC, HGDI_OBJECT );
>
> so every call to SelectObject requires a cast.
> it might be nice if you could alias on params
> i.e.
> alias HBRUSH SelectObject( HDC, HBRUSH ) SelectObject;
> alias HBITMAP SelectObject( HDC, HBITMAP ) SelectObject;
>
>
>
>
>
>