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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM,WEIRD_PORT autolearn=no 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 Path: g2news1.google.com!postnews.google.com!f20g2000vbc.googlegroups.com!not-for-mail From: Shark8 Newsgroups: comp.lang.ada Subject: Re: Properties Date: Fri, 3 Dec 2010 11:52:22 -0800 (PST) Organization: http://groups.google.com Message-ID: <75475874-cd6c-4e75-8a2f-7675ecf0864a@f20g2000vbc.googlegroups.com> 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> NNTP-Posting-Host: 174.28.198.93 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1291405943 7692 127.0.0.1 (3 Dec 2010 19:52:23 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 3 Dec 2010 19:52:23 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: f20g2000vbc.googlegroups.com; posting-host=174.28.198.93; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729; .NET4.0E),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:15778 Date: 2010-12-03T11:52:22-08:00 List-Id: On Dec 3, 2:05=A0am, "Dmitry A. Kazakov" wrote: > > Why not have an INTERFACE hierarchy in addition to the GUI_Object > > hierarchy? > > Hmm, isn't it same? To me interface =3D 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 lis= ts > 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 =3D> GUI_Base'Class, Index_Type =3D> 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 =3D> Index and Element =3D> 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:=3D GUI_Vector.Empty_Vector; Component_1 : Aliased GUI_Base'Class:=3D Make_Component( ... ); --... Component_n : Aliased GUI_Base'Class:=3D 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 widge= t > be a fat pointer transparent to all widget operations with automatic > collection of widget objects. This almost works in Ada, but it is extreme= ly > 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? > > =A0 =A0type Widget_Handle is private Widget; -- Like the widget, but isn'= t > private > =A0 =A0type Widget_Handle is new Ada.Limited_Controlled with record > =A0 =A0 =A0 =A0Ptr : access Widget; > =A0 =A0end record; > > For access types there must be delegation support, which should eliminate > need in wrappers. There are other issues as well, like that "access Widge= t" > 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 ou= r > customers explicitly ordered that. Now, my impression is opposite to your= s: > 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.