If anyone needs a little reminder of how not to implement a cross-platform library, I can suggest having a look at the Bluetooth library in Delphi.
If anyone needs a little reminder of how not to implement a cross-platform library, I can suggest having a look at the Bluetooth library in Delphi.
I'm not thinking of the API design on the whole here, but rather some very unfortunate design deficiencies and implementation decisions. When making cross-platform libraries it is difficult to expose all use-cases. Thus it's important to make allowances for the user to add platform-specific code if needed.
Unfortunately, the Bluetooth library couldn't make this any harder if it tried.
For example, a TBluetoothAdapter is an abstract class, which is implemented by TWinBluetoothAdapter on Windows. The TWinBluetoothAdapter class has a "radio handle" which is used when accessing the Windows Bluetooth API.
Not only is this handle hidden inside the protected section of the class, the TWinBluetoothAdapter class itself is declared in the implementation section of the unit. The same goes for most (if not all) of the implementing classes.
Thus a user has no way of inserting custom platform-specific code...
My specific issue is that the TBluetooth library does not give the user the ability to override the pairing process, even though the Windows API supports registering a callback to do just that. If the other platforms do not support this, then I can understand that the library API does not expose this.
But it should be possible for me to override this behavior without me having to keep my own "fork" of the library!
Typically one does this is by exposing the underlying handles or similar, so that it is possible to make direct calls to the underlying API if the user needs to. The documentation should of course state that using these may conjure fire-breathing dragons or have other side-effects. But give the user a way!
I'm not thinking of the API design on the whole here, but rather some very unfortunate design deficiencies and implementation decisions. When making cross-platform libraries it is difficult to expose all use-cases. Thus it's important to make allowances for the user to add platform-specific code if needed.
Unfortunately, the Bluetooth library couldn't make this any harder if it tried.
For example, a TBluetoothAdapter is an abstract class, which is implemented by TWinBluetoothAdapter on Windows. The TWinBluetoothAdapter class has a "radio handle" which is used when accessing the Windows Bluetooth API.
Not only is this handle hidden inside the protected section of the class, the TWinBluetoothAdapter class itself is declared in the implementation section of the unit. The same goes for most (if not all) of the implementing classes.
Thus a user has no way of inserting custom platform-specific code...
My specific issue is that the TBluetooth library does not give the user the ability to override the pairing process, even though the Windows API supports registering a callback to do just that. If the other platforms do not support this, then I can understand that the library API does not expose this.
But it should be possible for me to override this behavior without me having to keep my own "fork" of the library!
Typically one does this is by exposing the underlying handles or similar, so that it is possible to make direct calls to the underlying API if the user needs to. The documentation should of course state that using these may conjure fire-breathing dragons or have other side-effects. But give the user a way!
Same problem is for FMX platform canvas classes. You can't access to platform-specific fields without dirty hacks or implement own descendant. Very weird.
ReplyDeleteAt least you can simply write your own library code to do this. Often with libraries produced by Emba in recent times that's the best option. The halcyon days of the VCL seem far away.
ReplyDeleteDavid Heffernan True, though that kinda defeats the R in RAD. The sad part is that by simply moving a few declarations they could have done so much better...
ReplyDeleteNow, don't get me started on the REST client library...
I'm not trying to defend them. Just the reality. Quality is very low. Not surprising when they get rid of all the experienced developers and out source library development to the cheapest bidder.
ReplyDeleteI decided not to renew maintenance this week. Now planning port to C++ which does not sound like fun but at least I will have quality tools and libraries.
David Heffernan And you'll get your speed ;)
ReplyDeleteFor GUI, C++ is quite tedious in comparison to Delphi. Well I've only used WxWidgets and Qt4. But yeah, Delphi is quite nice there, especially with DevExpress components or similar.
But for most other things, I rather liked C++. Things like templates, RAII and const-ness made it much easier to not get surprises I thought.
GUI is not something I relish in C++. VCL is awesome. But I expect I can make it work. And having good tools and libraries will be something. A compiler that emits decent code. Oh joy.
ReplyDeleteClosed for modification, closed for extension
ReplyDeleteYes GUI is still such a mess in C++. Sad really. I have tried to like QT, really tried, but it's a horrible framework. I tried to like WxWidgets also but it's a completely horrible framework also. And C++ itself is a mess as a language. However, code generation from C++ compilers is excellent, including 64 bit, where real optimizations exist, and where code generation supports modern CPU instructions.
ReplyDeleteIn the end, to obtain a professional result, one must fight with the warts of C++, and at least, one can do anything, with enough skill and persistence.
With native cross platform C++ and the rich suite of libraries and toolkits and IDEs, it is possible to get good things built.
And with C++ on your resume, you're instantly hireable in 1000x more places these days, than with our dear old Delphi.