[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