Changing Original Library API when writing Wrappers

[Ingo Klöcker]

On Sonntag, 30. Januar 2022 14:20:10 CET Ayush Singh wrote:
> Hello everyone, I am currently working on a Rust Wrapper for KConfig
> KDE Framework (https://invent.kde.org/oreki/kconfig-rs) as part of
> Season of KDE 2022. For the most part, I have made the wrapping
> methods one-to-one with the C++ API. So they use the same arguments
> and return types as their C++ counterparts.
> 
> However, during this process, I have come across some methods where I
> can change the API in the Rust side to take better advantage of the
> Rust type system.
[...]
> There are more parts of KConfig similar to this. However, I wanted to
> know other people's opinions on how faithful should the Wrapper be to
> the original library in general. Is it better to have the same
> signatures as the underlying library as far as possible? Or is it
> better to break away from the library API when the Language allows
> having a stricter and 'misuse-resistant' API?

In my opinion, language bindings should feel natural to developers who know 
the language. After all, the main audience for a language binding is the 
developers programming in this language and not developers who are proficient 
in the original language.

The Rust binding of KConfig would ideally look like any other library written 
directly in Rust. So, by all means, make use of any features of Rust that make 
the Rust binding look less like a binding of a C++ library and more like a 
native Rust library.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20220130/9a74c76a/attachment.sig>