comp.lang.ada
 help / color / mirror / Atom feed
From: "Jeff Creem" <jeff@thecreems.com>
Subject: Re: Ada 0y wish list: "with private"
Date: Tue, 13 Feb 2001 07:01:24 -0500
Date: 2001-02-13T07:01:24-05:00	[thread overview]
Message-ID: <t8i8cuncosuo54@corp.supernews.com> (raw)
In-Reply-To: dale-1C6885.17292013022001@news-server

I think I see a little better what you are trying to accomplish. I am still
not sure I see
where this is really useful. I probably have addressed similar problems in
the past
somewhat differently by putting stuff from your private part in the public
area but then using
the Export set features of Rational Apex to limit what other packages can
with that special
package.

It does require a little more work on the part of the programmer but I think
it addresses more
cases. Perhaps (if it is not patented) we should look at the export set
feature of Apex for inclusion in
the language in some way.


"Dale Stanbrough" <dale@cs.rmit.edu.au> wrote in message
news:dale-1C6885.17292013022001@news-server...
> Jeff Creem  wrote:
>
> > I am not entirely wild about this. It seems like a great way to break
the
> > private abstraction and shoot
> > yourself. If C needs to need to know that much about B then it should be
a
> > child of B.
> >
> > Sure having something like this lets you be a little sloppier about the
> > interfaces you provide to users of
> > your package but without more of an example my gut tells me that you are
> > missing the reason things are
> > put in the private section.
>
>
> No, that's not the problem at all. It's not a matter of being
> sloppy, it's about having the freedom to compose the abstractions
> that you want to.
>
> For example i have a type declared in a private
> package, and would like this internal private type to be part of
> the completion of a public type in a public package in the
> package hierarchy. I never want the internal private type to be public,
> but Ada does not allow it.
>
> Currently we have compilation privacy - what i want is implementation
> privacy.
>
> For example
>
>
>    package A is
>    end A;
>
>    private package A.one is
>       type P1 is private;
>       procedure op1 (item : p1);
>    private
>       type P1 is something;
>    end;
>
>
>
>    with A.one;   -- can't do this.
>    package A.two is
>       type P2 is private;
>
>       procedure op2 (Item : P2);
>    private
>       type P2 is new P1;
>    end;
>
>
>    with private A.one;   -- would like to do this...
>    package A.two is
>       type P2 is private;
>
>       procedure op2 (Item : P2);
>    private
>       type P2 is new P1;
>    end;
>
> Certainly we are giving nothing away - the only operations available
> outside the hierarchy would be those declared in package A.two.
>
> Certainly it shouldn't be necessary to implement "with private", as
> a simple change to the rules (you can with the package, but if it
> is private, you can only mention it in the private section).
>
> What i want to do certainly does not compromise any of the data
> hiding abilities of the language as it stands. It only affects how
> things are compiled (it prevents clients from having to be recompiled
> if an internal private component is recompiled).
>
>
> dale





  reply	other threads:[~2001-02-13 12:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-12 13:41 Ada 0y wish list: "with private" Thierry Lelegard
2001-02-13  0:10 ` Keith Thompson
2001-02-13  0:13 ` Jeff Creem
2001-02-13  6:37   ` Dale Stanbrough
2001-02-13 12:01     ` Jeff Creem [this message]
2001-02-13  8:48 ` Dr Adrian Wrigley
2001-02-13  8:56 ` Michel Gauthier
2001-02-13 16:31 ` Ehud Lamm
  -- strict thread matches above, loose matches on Subject: below --
2001-02-15  1:04 Beard, Frank
2001-02-15  4:18 ` Jeffrey Carter
2001-02-15  4:53 Christoph Grein
2001-02-15 19:16 Beard, Frank
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox