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 autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,26a21b9e317dc639 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.224.207.66 with SMTP id fx2mr9599356qab.7.1353363225440; Mon, 19 Nov 2012 14:13:45 -0800 (PST) Received: by 10.49.24.14 with SMTP id q14mr2958152qef.17.1353363225409; Mon, 19 Nov 2012 14:13:45 -0800 (PST) Path: gf5ni327qab.0!nntp.google.com!u2no13805984qal.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 19 Nov 2012 14:13:45 -0800 (PST) In-Reply-To: <6e3f6f2d-d221-4795-9c01-9abb013442b7@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=206.53.78.59; posting-account=ShYTIAoAAABytvcS76ZrG9GdaV-nXYKy NNTP-Posting-Host: 206.53.78.59 References: <9b0bcb37-8ae3-440f-af4f-a796702e4250@googlegroups.com> <6e3f6f2d-d221-4795-9c01-9abb013442b7@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <0180db35-c92b-4cf5-93b4-1da2ff3afb0f@googlegroups.com> Subject: Re: Access type to member procedure of instance (Object Oriented programming in Ada) From: sbelmont700@gmail.com Injection-Date: Mon, 19 Nov 2012 22:13:45 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-11-19T14:13:45-08:00 List-Id: On Monday, November 19, 2012 3:52:17 PM UTC-5, ake.ragna...@gmail.com wrote= : > I hope I am wrong but it seems to me that since Ada lacks the ability to = create pointers (maybe access types are the right words) to instance member= methods, it is not possible to take advantage of Ada's OOP features when d= eveloping Glade3 applications. >=20 The first problem is that "pointers to instance member methods" is a contri= diction in terms; methods are *part* of an object, not some independent 'th= ing' that can ever exist or be executed otherwise. Given an object, you ac= cess it's subprograms, not the other way around. It's even stated in the L= RM: "Note that using an access-to-class-wide tagged type with a dispatching= operation is a potentially more structured alternative to using an access-= to-subprogram type." IMHO, the offending programs should be redesigned, no= t kludges added to the language. The second problem is that GTK is a C-based, procedural API. It was kind-o= f/sort-of "OOP-ized" for Gtk-Ada, but there are many parts that are still v= ery procedural and reek of C. The fact that you are registering callback p= rocedures (instead of objects) is a dead giveaway that you are not dealing = strictly with OOP. -sb