Re: Properties

[Warren <ve3wwg@gmail.com>]

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? Leave 
the task handling to the application designer.

> 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.

> 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.

>> Part of the difficulty is that something like a GUI takes
>> so much effort to develop. To get one developed to a
>> "standard level" would likely require some level of
>> sponsorship. Especially if you want to also attempt to
>> make it platform neutral.
> 
> The main problem is the interface of such a library. There
> are multiple parallel hierarchies need to be handled: a
> hierarchy of widget types, a hierarchy of widget
> containers, 

There are some challenges there, but I don't believe the fact 
that you need widget containers is a show stopper.

> a hierarchy of event handlers (events are 
> filtered, propagated, swallowed, re-generated). 

Not a problem with the callback approach, AFAICS.

> 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.

> 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.

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.

> Then
> there is a fourth hierarchy of widget properties. Some of
> the properties are inherited from parent types, some are
> from parent containers.
> 
> All these hierarchies must play with each other. Ada's type
> system is not mature for this.

Perhaps not mature enough for your requirements. 

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.

Are there any GUI systems implemented that are fully static 
checked?

Warren