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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,b8b8a54001adc4d2 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!news-feed01.roc.ny.frontiernet.net!nntp.frontiernet.net!newscon06.news.prodigy.com!prodigy.net!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Possible Ada deficiency? Date: 10 Jan 2005 17:16:26 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <1104516913.718856.94090@z14g2000cwz.googlegroups.com> <1105290947.422412.195950@c13g2000cwb.googlegroups.com> <1105327217.641306.80180@c13g2000cwb.googlegroups.com> NNTP-Posting-Host: shell01-e.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1105395387 31251 69.38.147.31 (10 Jan 2005 22:16:27 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Mon, 10 Jan 2005 22:16:27 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:7627 Date: 2005-01-10T17:16:26-05:00 List-Id: danmcleran@hotmail.com writes: > Well, then why not make everything public and forget the whole idea of > encapsulation altogether? I've no idea what you're replying to here, but note that the point of the visibility rules is documentation: you can tell, by reading the code, which hunks of code can access which variables. There is no security goal here (i.e. prevent evil programmers from accessing variables they shouldn't). Why not go even further than your 'concealed' idea? As in Eiffel, where each class can name which other classes are allowed to meddle with particular features of this class. By the way, there's one question you haven't answered. You desire to prevent children from accessing parent-private stuff. OK, that's a legitimate concern. But if you have a package X.Y that does not want to access private-X stuff, then why do you want it to be a child in the first place? In my suggested solution, X could declare "I have no children", and then Y would have to be *not* a child of X. But obviously it doesn't *need* to be a child of X, since it does not access private-X stuff. Note that you can always declare an *empty* root package X, and have children Y and Z that cannot access each other's private stuff. And with my suggestion you could declare X.Y and/or X.Z to have no children. No children implies children cannot access private stuff! - Bob