Quantcast

Win32 non-backwards compatible API change

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Win32 non-backwards compatible API change

Tamar Christina
Hi All,

I want to revive and push forward a change first proposed in 2014 for an API
change in the Win32 package.

The discussion at that time took place here https://github.com/haskell/win32/issues/24

In short, In the Windows API it is common that when a function accepts a pointer to something,
that NULL also be valid and defaults to some action. Such an example is the FindWindow call.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms633499(v=vs.85).aspx

HWND WINAPI FindWindow(
  _In_opt_ LPCTSTR lpClassName,
  _In_opt_ LPCTSTR lpWindowName
);

In this case, both the ClassName and the WindowName are allowed to be NULL.

The Haskell binding to this function is findWindow :: String -> String -> IO (Maybe HWND).
So we've lost the ability to use the default parameters.

The proposal is to change such functions to accept Maybe:

findWindow :: String -> String -> IO (Maybe HWND)

becomes

findWindow :: Maybe String -> Maybe String -> IO (Maybe HWND)

Which also would more accurately match the original API. This is of course a backwards incompatible change.

Any objections to this change?

Thanks,
Tamar



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Win32 non-backwards compatible API change

Elliot Cameron-2
As painful as the transition might be, we desperately need to set this right sooner rather than later. The number of libraries depending on win32 is not going to decrease over time.

+1

On Jan 27, 2017 7:54 AM, "Tamar Christina" <[hidden email]> wrote:
Hi All,

I want to revive and push forward a change first proposed in 2014 for an API
change in the Win32 package.

The discussion at that time took place here https://github.com/haskell/win32/issues/24

In short, In the Windows API it is common that when a function accepts a pointer to something,
that NULL also be valid and defaults to some action. Such an example is the FindWindow call.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms633499(v=vs.85).aspx

HWND WINAPI FindWindow(
  _In_opt_ LPCTSTR lpClassName,
  _In_opt_ LPCTSTR lpWindowName
);

In this case, both the ClassName and the WindowName are allowed to be NULL.

The Haskell binding to this function is findWindow :: String -> String -> IO (Maybe HWND).
So we've lost the ability to use the default parameters.

The proposal is to change such functions to accept Maybe:

findWindow :: String -> String -> IO (Maybe HWND)

becomes

findWindow :: Maybe String -> Maybe String -> IO (Maybe HWND)

Which also would more accurately match the original API. This is of course a backwards incompatible change.

Any objections to this change?

Thanks,
Tamar



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Win32 non-backwards compatible API change

Gauthier Segay
I was thinking the transition for this kind of change should be easy
by defining the same function in project using it in many places:

findWindow lpClassName lpWindowName = WIN32.findWindow (Just
lpClassName) (Just lpWindowName)

this allow quick fix of code base without changes at call sites (just
one import)

this is unless users are willing to change each call sites, which
shouldn't be too much trouble with help of compiler



On Fri, Jan 27, 2017 at 4:19 PM, Elliot Cameron <[hidden email]> wrote:

> As painful as the transition might be, we desperately need to set this right
> sooner rather than later. The number of libraries depending on win32 is not
> going to decrease over time.
>
> +1
>
> On Jan 27, 2017 7:54 AM, "Tamar Christina" <[hidden email]> wrote:
>>
>> Hi All,
>>
>> I want to revive and push forward a change first proposed in 2014 for an
>> API
>> change in the Win32 package.
>>
>> The discussion at that time took place here
>> https://github.com/haskell/win32/issues/24
>>
>> In short, In the Windows API it is common that when a function accepts a
>> pointer to something,
>> that NULL also be valid and defaults to some action. Such an example is
>> the FindWindow call.
>>
>>
>> https://msdn.microsoft.com/en-us/library/windows/desktop/ms633499(v=vs.85).aspx
>>
>> HWND WINAPI FindWindow(
>>   _In_opt_ LPCTSTR lpClassName,
>>   _In_opt_ LPCTSTR lpWindowName
>> );
>>
>> In this case, both the ClassName and the WindowName are allowed to be
>> NULL.
>>
>> The Haskell binding to this function is findWindow :: String -> String ->
>> IO (Maybe HWND).
>> So we've lost the ability to use the default parameters.
>>
>> The proposal is to change such functions to accept Maybe:
>>
>> findWindow :: String -> String -> IO (Maybe HWND)
>>
>> becomes
>>
>> findWindow :: Maybe String -> Maybe String -> IO (Maybe HWND)
>>
>> Which also would more accurately match the original API. This is of course
>> a backwards incompatible change.
>>
>> Any objections to this change?
>>
>> Thanks,
>> Tamar
>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Win32 non-backwards compatible API change

Tamar Christina

 > findWindow lpClassName lpWindowName = WIN32.findWindow (Just
 > lpClassName) (Just lpWindowName)
 >  
 > this allow quick fix of code base without changes at call sites (just
 > one import)

I also thought about providing an old-win32 package which did this, but it wouldn't get
any further update so I'm not sure it's worth it. Would certainly increase the maintenance.

Most packages have strict version bounds on Win32, (as I found out when updating GHC's shipping version).

So I think for most people they'd have to opt in to this version.

 >  
 > this is unless users are willing to change each call sites, which
 > shouldn't be too much trouble with help of compiler
 >  
 >  
 >  
 > On Fri, Jan 27, 2017 at 4:19 PM, Elliot Cameron <[hidden email]> wrote:
 > > As painful as the transition might be, we desperately need to set this right
 > > sooner rather than later. The number of libraries depending on win32 is not
 > > going to decrease over time.
 > >
 > > +1
 > >
 > > On Jan 27, 2017 7:54 AM, "Tamar Christina" <[hidden email]> wrote:
 > >>
 > >> Hi All,
 > >>
 > >> I want to revive and push forward a change first proposed in 2014 for an
 > >> API
 > >> change in the Win32 package.
 > >>
 > >> The discussion at that time took place here
 > >> https://github.com/haskell/win32/issues/24 
 > >>
 > >> In short, In the Windows API it is common that when a function accepts a
 > >> pointer to something,
 > >> that NULL also be valid and defaults to some action. Such an example is
 > >> the FindWindow call.
 > >>
 > >>
 > >> https://msdn.microsoft.com/en-us/library/windows/desktop/ms633499(v=vs.85).aspx 
 > >>
 > >> HWND WINAPI FindWindow(
 > >>   _In_opt_ LPCTSTR lpClassName,
 > >>   _In_opt_ LPCTSTR lpWindowName
 > >> );
 > >>
 > >> In this case, both the ClassName and the WindowName are allowed to be
 > >> NULL.
 > >>
 > >> The Haskell binding to this function is findWindow :: String -> String ->
 > >> IO (Maybe HWND).
 > >> So we've lost the ability to use the default parameters.
 > >>
 > >> The proposal is to change such functions to accept Maybe:
 > >>
 > >> findWindow :: String -> String -> IO (Maybe HWND)
 > >>
 > >> becomes
 > >>
 > >> findWindow :: Maybe String -> Maybe String -> IO (Maybe HWND)
 > >>
 > >> Which also would more accurately match the original API. This is of course
 > >> a backwards incompatible change.
 > >>
 > >> Any objections to this change?
 > >>
 > >> Thanks,
 > >> Tamar
 > >>
 > >>
 > >>
 > >> _______________________________________________
 > >> Libraries mailing list
 > >> [hidden email]
 > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries 
 > >
 > >
 > > _______________________________________________
 > > Libraries mailing list
 > > [hidden email]
 > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries 
 > >
 >
 >



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Win32 non-backwards compatible API change

Gauthier Segay
the reasoning is that user upgrading can easily define that function
which save changing each call site; this makes the breaking change
reasonable to me.

On Fri, Jan 27, 2017 at 6:49 PM, Tamar Christina <[hidden email]> wrote:

>
>  > findWindow lpClassName lpWindowName = WIN32.findWindow (Just
>  > lpClassName) (Just lpWindowName)
>  >
>  > this allow quick fix of code base without changes at call sites (just
>  > one import)
>
> I also thought about providing an old-win32 package which did this, but it wouldn't get
> any further update so I'm not sure it's worth it. Would certainly increase the maintenance.
>
> Most packages have strict version bounds on Win32, (as I found out when updating GHC's shipping version).
>
> So I think for most people they'd have to opt in to this version.
>
>  >
>  > this is unless users are willing to change each call sites, which
>  > shouldn't be too much trouble with help of compiler
>  >
>  >
>  >
>  > On Fri, Jan 27, 2017 at 4:19 PM, Elliot Cameron <[hidden email]> wrote:
>  > > As painful as the transition might be, we desperately need to set this right
>  > > sooner rather than later. The number of libraries depending on win32 is not
>  > > going to decrease over time.
>  > >
>  > > +1
>  > >
>  > > On Jan 27, 2017 7:54 AM, "Tamar Christina" <[hidden email]> wrote:
>  > >>
>  > >> Hi All,
>  > >>
>  > >> I want to revive and push forward a change first proposed in 2014 for an
>  > >> API
>  > >> change in the Win32 package.
>  > >>
>  > >> The discussion at that time took place here
>  > >> https://github.com/haskell/win32/issues/24
>  > >>
>  > >> In short, In the Windows API it is common that when a function accepts a
>  > >> pointer to something,
>  > >> that NULL also be valid and defaults to some action. Such an example is
>  > >> the FindWindow call.
>  > >>
>  > >>
>  > >> https://msdn.microsoft.com/en-us/library/windows/desktop/ms633499(v=vs.85).aspx
>  > >>
>  > >> HWND WINAPI FindWindow(
>  > >>   _In_opt_ LPCTSTR lpClassName,
>  > >>   _In_opt_ LPCTSTR lpWindowName
>  > >> );
>  > >>
>  > >> In this case, both the ClassName and the WindowName are allowed to be
>  > >> NULL.
>  > >>
>  > >> The Haskell binding to this function is findWindow :: String -> String ->
>  > >> IO (Maybe HWND).
>  > >> So we've lost the ability to use the default parameters.
>  > >>
>  > >> The proposal is to change such functions to accept Maybe:
>  > >>
>  > >> findWindow :: String -> String -> IO (Maybe HWND)
>  > >>
>  > >> becomes
>  > >>
>  > >> findWindow :: Maybe String -> Maybe String -> IO (Maybe HWND)
>  > >>
>  > >> Which also would more accurately match the original API. This is of course
>  > >> a backwards incompatible change.
>  > >>
>  > >> Any objections to this change?
>  > >>
>  > >> Thanks,
>  > >> Tamar
>  > >>
>  > >>
>  > >>
>  > >> _______________________________________________
>  > >> Libraries mailing list
>  > >> [hidden email]
>  > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>  > >
>  > >
>  > > _______________________________________________
>  > > Libraries mailing list
>  > > [hidden email]
>  > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>  > >
>  >
>  >
>
>
>
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Loading...