Re: Properties

["Randy Brukardt" <randy@rrsoftware.com>]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:75475874-cd6c-4e75-8a2f-7675ecf0864a@f20g2000vbc.googlegroups.com...
...
>It is somewhat irritating that you cannot initialize element to
>GUI_Base'Class directly.

You can do this with the Ada containers.

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

Right, but you are using the wrong container for this. Try the indefinite 
containers (designed specifically for this purpose):

Package GUI_Vector is New Ada.Containers.Indefinite_Vectors
   ( Element_Type => GUI_Base'Class, Index_Type => Positive );

This will work fine.

                              Randy.



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.