Re: Properties

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 1 Dec 2010 16:20:44 +0000 (UTC), Warren wrote:

> Dmitry A. Kazakov expounded in
> news:1k7367gtebsgm$.18auo6u3nfg34.dlg@40tude.net: 
> 
>> On Wed, 1 Dec 2010 15:21:39 +0000 (UTC), Warren wrote:
>>> A library designed in Ada from the ground up, would be
>>> better. 
>> 
>> But we cannot, think about a type- and task-safe
>> notification mechanism. I have no idea how to do it without
>> tagged tasks and protected objects. 
> 
> Perhaps the scope you have in mind is too large. Is it really 
> necessary to have the GUI operate outside of one task?

Affirmative. Consider an oscilloscope widget indicating real-time data.
Consider a debug window showing log messages from different tasks. The
worst thing of GTK is that it is not task-safe.

> Leave the task handling to the application designer.

Obtrusive and inefficient. I did it for GtkAda. It is quite uncomfortable
to use, and if you forget to route GTK requests to the main task, you get
sporadic crashes difficult to trace down, quite nasty.

>> And I don't want to
>> instantiate a generic each time I need an event handler.
> 
> Agreed, but I don't believe we're stuck with that solution. 
> All you need is procedure'Access for the callback.

No, because events have parameters and those must be typed. The standard
solution is that you instantiate a generic (and there is one for each
number of parameters and the results). That is extremely boring.

>> And I do want the compiler to check that all events are
>> handled. 
> 
> Hmmm, more of a scope problem, I think.  Your requirements may 
> be part of the problem.

But otherwise you would have to frantically search for the handler that
caught the event you expected the widget to propagate, just to learn that
the widget does not propagate it at all. Even better if you create an
events generator that covers all desktop with multiplying pop-up windows. I
hate this stuff.

>> At least
>> the first and the third must be statically checked, if we
>> really want it be Ada. 
> 
> Callbacks (events) are dynamic by nature. I think the best you 
> can hope for is that your event handler is the correct kind 
> (of callback) and that any parameters match are of the correct 
> type. Both areas that Ada excells at.
> 
> Asking for more than that, is perhaps a requirements problem.

Maybe, but I expect excellence from a standard library.

>> Very likely that some composite
>> widgets (the second hierarchy) should also be static. 
> 
> I think tagged records are going to be the only real solution 
> here, which is going to forgo static analysis.

Yes, this is my impression too.

> I think a tagged solution is at least as good as a C++ 
> solution, but better due to Ada strengths.  I think many folks 
> could live with the dynamic nature of an Ada GUI library.

BTW, most likely multiple inheritance will be needed. There is a huge
resistance to MI in Ada. I have no idea why, nobody managed to articulate
anything but prejudices and urban legends.

> It really comes down to what is "good enough" for a standard 
> GUI library. Your requirements are desirable, but with 
> existing software technologies, it doesn't appear practical 
> AFAICS.

They are practical at least in pushing Ada into a right direction. (I
guess, the reason why I agree with Randy most of the time is because he
maintains CLAW and I do the GtkAda contributions. This keeps us on the same
page.)
 
> Are there any GUI systems implemented that are fully static 
> checked?

I guess no.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de