From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,36a29c2860aff686 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!proxad.net!feeder1-2.proxad.net!news.in2p3.fr!in2p3.fr!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Properties Date: Fri, 3 Dec 2010 15:14:09 -0600 Organization: Jacob Sparre Andersen Message-ID: References: <3b84c8e7-1a51-4a7c-9646-119f1fc51478@s4g2000yql.googlegroups.com> <4pnv7nl4cdui$.1n28i7lqk4mek$.dlg@40tude.net> <1k7367gtebsgm$.18auo6u3nfg34.dlg@40tude.net> <083addb2-61f6-4a69-bb81-2e4fa640783b@e16g2000pri.googlegroups.com> <124c5qinlvj7c$.1pdr35p7hkp11.dlg@40tude.net> <75475874-cd6c-4e75-8a2f-7675ecf0864a@f20g2000vbc.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1291410851 3144 69.95.181.76 (3 Dec 2010 21:14:11 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 3 Dec 2010 21:14:11 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Xref: g2news2.google.com comp.lang.ada:16756 Date: 2010-12-03T15:14:09-06:00 List-Id: "Shark8" 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.