Ptr or Ref

[mgkuhn]

Pre-defined Win32 API aliases for bits types such as

const BYTE = Cuchar
const BOOL = Cint
const BOOLEAN = BYTE
const DOUBLE = Cdouble
const DWORD = Culong

seem mostly uncontroversial and straight forward.

But what about aliases for pointer types, such as

const PDWORD = Ptr{DWORD}
const LPDWORD = Ptr{DWORD}

Should these really be Ptr{} or Ref{}?

Or should they remain undefined, to force the user to think about that difference for each use case themselves? In other words, should the user not write Ptr{HANDLE} or Ref{HANDLE} instead of PHANDLE?

Or should bits aliases, Ptr{} aliases and Ref{} aliases all go into separate modules or submodules, so that the Ptr{} vs Ref{} choice can be made by the user at import time?

Could the documentation for these types provide some more guidance on pointers?

(I don't have any answers yet; I just wanted to open an issue to collect thoughts on the subject.)

See also When to use T, Ptr{T} and Ref{T}

[musm]

Yeah, this is a good discussion to have, since I'm not sure what would be the best solution here.

I think my initial idea was to keep them as Ptr and if the user needed a reference in cases when the value is needed, they would naturally then be forced to use, e.g., Ref{DWORD}.

Or should bits aliases, Ptr{} aliases and Ref{} aliases all go into separate modules or submodules, so that the Ptr{} vs Ref{} choice can be made by the user at import time?

This is an interesting idea. Perhaps, Ptr definitions would remain the main source file and a submodule for Refs could be created.

The initial example in the README would end up looking like:

function get_console_mode()
    STD_OUTPUT_HANDLE = -11
    hOutput = ccall(:GetStdHandle, stdcall, HANDLE, (DWORD,), STD_OUTPUT_HANDLE % DWORD)
    dwMode = WinTypes.Ref.LPDWORD()
    ccall(:GetConsoleMode, stdcall, BOOL, (HANDLE, WinTypes.Ref.LPDWORD), hOutput, dwMode)
    return dwMode[]
end

Is that type of usage desirable?