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,268e52cd81f7181c
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,UTF8
Path: 
 g2news1.google.com!postnews.google.com!h7g2000yqn.googlegroups.com!not-for-mail
From: Maciej Sobczak <see.my.homepage@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: GNAT bug - still in 2010?
Date: Wed, 27 Oct 2010 13:43:24 -0700 (PDT)
Organization: http://groups.google.com
Message-ID: <a5a4bdce-04ef-4bfd-8ed8-d7d19bfe1ebb@h7g2000yqn.googlegroups.com>
References: 
 <6cebf1a3-3b2a-4e79-a39e-669a6a5ca00c@l20g2000yqm.googlegroups.com>
 <ia9iva$o2o$1@news.eternal-september.org>
NNTP-Posting-Host: 85.1.243.81
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Trace: posting.google.com 1288212204 19504 127.0.0.1 (27 Oct 2010 20:43:24
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Wed, 27 Oct 2010 20:43:24 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: h7g2000yqn.googlegroups.com; posting-host=85.1.243.81;
 posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8,gzip(gfe)
Xref: g2news1.google.com comp.lang.ada:14858
Date: 2010-10-27T13:43:24-07:00
List-Id: <comp.lang.ada>

On 27 Pa=C5=BA, 18:11, "Alexander S. Mentis" <f...@invalid.invalid> wrote:

> Yes, under Windows it demonstrates the same behavior.

Thank you. It is a real shame.

I thought that it might be possible to work around the problem with a
mix-in - that is, instead of deriving the protected type from
interface, move the interface down as a component of the protected
type. The additional type derived from the interface would take the
access discriminant pointing to the enclosing protected object and
delegate dispatching calls to the protected object.
Something like this:

   package P is
      type My_Interface is limited interface;
      procedure Do_Something (X : in out My_Interface) is abstract;
   end P;

   type My_Protected;
   type My_Interface_Mixin (Parent : access My_Protected) is
     new P.My_Interface with null record;

   --  the top-level protected type is no longer
   --  derived from My_Interface...:
   protected type My_Protected is
      procedure Do_Something;
   private
      --  ...and instead the derived type is now here,
      --  bound to the enclosing object:
      Mixin : My_Interface_Mixin (My_Protected'Access);
   end My_Protected;

   overriding
   procedure Do_Something (X : in out My_Interface_Mixin) is
   begin
      --  delegate to the enclosing protected object
      X.Parent.all.Do_Something;
   end Do_Something;

   protected body My_Protected is
      procedure Do_Something is
      begin
         null;
      end Do_Something;
   end My_Protected;


Guess what? The compiler crashes again. Does it deserve a distinct bug
report?

In any case, I would like to ask you whether the above approach makes
sense as a programming technique. It does not compile :-), but I would
like to know if from the idiomatic point of view it is constructed
properly.
What bothers me is whether it is possible to declare overriding
operation Do_Something for My_Interface_Mixin after the completion of
My_Protected - that is, isn't My_Interface_Mixin already frozen there?

(what a mess)

--
Maciej Sobczak * http://www.inspirel.com