Re: Properties

[Shark8 <onewingedshark@gmail.com>]

On Dec 3, 2:05 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> > Why not have an INTERFACE hierarchy in addition to the GUI_Object
> > hierarchy?
>
> Hmm, isn't it same? To me interface = abstract type.

Usually they are interchangeable, but INTERFACES are the only way in
Ada to do something akin to multiple inheritance: i.e. it is the only
way that we can synthesize a spin-box {an increase value button, a
decrease value button, and a numeric-value edit-box} from the leaves
of our elemental-GUI-component hierarchy w/o encapsulating the items
within an otherwise useless 'container' object.

   Type GUI_Base is interface;
   Procedure On_Basic_Event(Object : In Out GUI_Base'Class;
                            Event : In Basic_Event'Class
                           );

   Type Button is interface and GUI_base;
   Procedure On_Click( Object : In Out Button'Class;
                       Click  : In Click_Event'Class
                     );

   Type Edit_Box is interface and GUI_Base;
   Procedure On_Change( Object : In Out Edit_Box'Class;
                        Change : In Change_Event'Class
                      );

   -- ...

   Type Spin_Box_Object is New GUI_Base_Object and Button and Edit_box
with
      record
         --...
      end record;



> > Additionally, it could help with keeping the GUI_Object hierarchy
> > smaller as there are many GUI items which are themselves composed of
> > other GUI items. A scroll-bar, for example, has two distinct
> > interfaces: the Button[s] and the slider-bar.
>
> Ada should have had proper multiple inheritance 15 years ago.

Mayhaps; but that would be irrelevant to actual task. (i.e.  where
someone plops down and says to your boss "We're using Ada 2005 and we
want a GUI library fully and seamlessly portable across X, Y, and Z
OSes." who then turns to you and me and says "Make it!")

> > By "widget containers" do you mean something like
> > Ada.Containers.Vectors initialized to the classwide-type of the root
> > of the GUI_Object hierarchy, OR do you mean some component which
> > contains other components (like a panel, perhaps)? {I'm inclined to
> > believe you meant the latter.}
>
> Yes, the latter, but the former is also required, you frequently need lists
> of widgets (of referential semantics).

It is somewhat irritating that you cannot initialize element to
GUI_Base'Class directly.

Attempting the following
   Package GUI_Vector is New Ada.Containers.Vectors
	( Element_Type => GUI_Base'Class, Index_Type => Positive );
yields
instantiation error at a-convec.ads:321
"unconstrained element type in array declaration actual for
"Element_Type" must be a definite subtype"

What's wrong with say initializing Ada.Containers.Vector with Positive
=> Index and Element => Access_GUI_Base_Class*?

*Type Access_GUI_Base_Class is Access GUI_Base'Class;

It would be nice to throw a "Not null" in because storing a 'pointer'
to "not an object" is pretty dumb... but that gives this error-set:
warning: in instantiation at a-convec.adb:1196
warning: (Ada 2005) null-excluding objects must be initialized
warning: "Constraint_Error" will be raised at run time
warning: in instantiation at a-convec.adb:1209
warning: (Ada 2005) null-excluding objects must be initialized
warning: "Constraint_Error" will be raised at run time

It's almost as if it's saying that we couldn't ever use the container
exclusively like this:

Vector : GUI_Vector.Vector:= GUI_Vector.Empty_Vector;
Component_1 : Aliased GUI_Base'Class:= Make_Component( ... );
--...
Component_n : Aliased GUI_Base'Class:= Make_Component( ... );
begin
 Vector.Add( Component_1'Access );
--...
 Vector.Add( Component_n'Access );
--the work
end;

>This raises another question. Ada
> does not support abstract access types. You want a reference to the widget
> be a fat pointer transparent to all widget operations with automatic
> collection of widget objects. This almost works in Ada, but it is extremely
> boring to do.

[snip]
> The bottom line, interfaces must be removed from Ada.
> Instead of that an interface must be made inheritable
> from any concrete type. This is the same idea as with
> abstract record, array etc types.

Wouldn't this be alleviated by two things:
Allowing INTERFACE [keyword] objects to have fields (properties as
I've described, or somesuch)?
Allowing objects some sort of self/this/me attribute where the result
is a Not Null Access to its classwide-type*? (Or am I misunderstanding
what you mean by the need for "a fat pointer transparent to all widget
operations"?)

*Or is this the equivalent of requiring all such variables to be
Aliased?

>
>    type Widget_Handle is private Widget; -- Like the widget, but isn't
> private
>    type Widget_Handle is new Ada.Limited_Controlled with record
>        Ptr : access Widget;
>    end record;
>
> For access types there must be delegation support, which should eliminate
> need in wrappers. There are other issues as well, like that "access Widget"
> is purposely not "access Widget'Class."
>
> > Finally, I've been quite impressed with Delphi's Visual Component
> > Library (VCL).
>
> That's interesting, because we are using the VCL quite heavily. One of our
> customers explicitly ordered that. Now, my impression is opposite to yours:
> it is safer, *quicker*, cleaner, an far more maintainable to develop GUI in
> *raw* Windows API than in VCL. As a bonus, you can get rid of that awful
> Borland C++, use VC++ or gcc instead.

Oh, right, the VCL *WAS* ported-over-to/interfaced-with Borland's C
Builder. I'm utterly unfamiliar with that incarnation of the VCL as my
experience with it has been on the Delphi (Object Pascal) side.

But the problem is that wrapping the API calls, and management of the
returned references, in objects yields something similar-in-structure
to the VCL, no?

I'm not saying that things couldn't have been done better; they could
have. But for being a useful object-oriented GUI library tied to a
singular API (Windows) I think it's done pretty well.

The idea we've been kicking around about a truly portable GUI library
with attention to type-safety and [hopefully] prevention of Bad Things
(insofar as they can be prevented, thus your desire for a statically-
checked GUI library) is an order of magnitude more complex. -- Though
I myself would like to see just such a portable GUI library done in
Ada.

>
> > Microsoft's MFC and Java's JFC seem to have been
> > 'inspired' [or copied] from the VCL, but neither presents itself as
> > uniform & usable/mature [if you will] as the VCL.
>
> We dropped MFC long ago and never returned to it. We didn't use JFC, so I  cannot say anything about it.

Imagine the VCL, then take away all the inherited handling of events
and make them all purely java-interfaces (so in order to handle events
you have to create some class which implements the interface; this is
usually cone in-line/via-anonymous-class), and you basically have
something similar to the JFC.