Re: Properties

[Maciej Sobczak <see.my.homepage@gmail.com>]

On Dec 1, 10:45 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:

> > And how is this any different from, say, printing exactly the same log
> > messages on standard output?
>
> It is just same. You can safely call Put_Line from any task.

Wrong (AARM Annex A, 3.a):

"simultaneous calls to Text_IO.Put will work properly, so long as they
are going to two different files. On the other hand, simultaneous
output to the same file constitutes erroneous use of shared
variables."

You might argue that by analogy two tasks should be able to modify the
content of two distinct widgets, but that would be stretching
definitions, as the agreement of what is "distinct" in GUI is quite
arbitrary (ultimately, everything is a "child" of some uber-container,
like a display and shares, so nothing is really distinct).

> But if you do
> Set_Text in GTK, that will crash your program.

You mean - that will lead to erroneous execution? So it is exactly the
same as with printing on standard output.

Why do you expect to get better guarantees from GUI than from stdout?

> > How do you solve this problem with Ada.Text_IO? Why the same solution
> > cannot apply to GUI?
>
> I would like to have a similar solution, i.e. GUI things working without
> switching the contexts.

"Switching the contexts" is a technical term that relates to some
platform implementation details. I don't see why this is relevant to
GUIs, certainly not for performance reasons.

And again, this is the same as with standard output.

> On the context of the main GTK task you just call Set_Text. From an alien
> task you need to instantiate a generic, or pass a closure, or override a
> primitive operation of a query object and from the callback call to
> Set_Text. The router calls the callback on the context of the main task.
> You would not do this for each graphic operations. Instead you have a sort
> of transactions, sets of operations executed in a group. This makes the
> code look very different. As I said it is obtrusive.

Is this a GUI problem or a general language problem?
And is this really a proper design?

I have implemented a GUI application recently. Not in Ada, but the
general concepts are transferrable, as the tasking constraints were
the same.
The design involved a separate encapsulating "gui" package that
exposed subprograms for *logical* (ie. domain-level) manipulations of
the displayed content. The actual domain-oriented tasks of the
application were not concerned with "setting a new text value of some
widget", but rather with updating the domain-level information,
whatever it was. By doing this, I have achieved not only the physical
encapsulation of the display part and loose coupling between
functional modules (heck, I could change that to a web service without
touching anything else), which solved the tasking constraints, but
also raised the level of operation for the rest of the program. And I
don't consider it to be "obtrusive".

With this experience in mind, if you insist on GUI to be task-safe, I
think it is because you want the GUI library to support poor design
practices. Having arbitrary application tasks calling Set_Text
directly on some widget sounds like spaghetti.
And that's why I'm not convinced.

--
Maciej Sobczak * http://www.inspirel.com