[gtkada] GtkAda signal handlers interface proposal
Dmitry A. Kazakov
mailbox at dmitry-kazakov.de
Thu Apr 28 14:43:14 CEST 2016
On 28/04/2016 14:28, Emmanuel Briot wrote:
>> And this is never an issue in my case. If there is a remote
>> possibility that a signal will be delivered to a prematurely
>> destroyed object, I see no way how something may get leaked. All
>> objects are put into some containers which deal with their
>> referencing/unreferencing. Anything else is bad design, in my view,
>> it should be prevented from happening rather than dealt with at run
>> time.
> Right, and that's why I am saying that the current proposal, as it stands, is bad design. It is easy to get leaks, or
> even invalid memory access.
Not if the parameter where plain object.
But even if it is an access type, it is no different from any other
place in GtkAda where you can call new Gtk_Button and pass an
uninitialized object almost everywhere. If you want prevent this, all
types must be limited unconstrained to prevent illegitimate object
declarations and allocators.
> Knowing when to call Unref is not so easy (the answer is that you need a Weak_Ref on the emitted widget, and I
> would guess that most people don't know what a weak ref is).
>
>> Not really, we don't want to be forced to type conversions when using public interfaces. Especially the conversions that may fail at run-time and crash whole application
> Sorry, can't crash your application.
> You will get a Constraint_Error (assuming you are passing the wrong type), and such exceptions are handled by GtkAda,
> always, before it gives the control back to the C layer. So no crash.
The scenario is when the user forgets to specify the Slot parameter, and
when he will try to convert the parameter Constraint_Error will
propagate and consequently crash the application. Using the Slot
parameter is untyped and inherently unsafe.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/gtkada/attachments/20160428/c319f3b1/attachment.html>
More information about the gtkada
mailing list