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-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,23cf9f1e93744eed
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-07-31 10:29:47 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!lnsnews.lns.cornell.edu!news.litech.org!news-feed.riddles.org.uk!sn-xit-03!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Need advice re package organization.
Date: Thu, 31 Jul 2003 12:31:29 -0500
Organization: Posted via Supernews, http://www.supernews.com
Message-ID: <viikgadbm4n1e4@corp.supernews.com>
References: <pan.2003.07.26.13.08.25.810488@mail.utexas.edu>
 <3F228F3B.9020203@attbi.com> <yaxUa.374$XK4.16279@read1.cgocable.net>
 <3F22F9E9.3040307@attbi.com> <M2YUa.972$XK4.65085@read1.cgocable.net>
 <5jn9ivoetll1fu2avn9hmjj6aaa7q7pmjn@4ax.com>
 <y%xVa.1302$j_5.4631@news20.bellglobal.com>
 <fiveiv8h309dkvjqf6nb343osfjl41qt3o@4ax.com>
 <clWVa.4191$mv6.741217@news20.bellglobal.com>
 <vigijhb0op0t69@corp.supernews.com>
 <7DbWa.1370$qN3.183518@news20.bellglobal.com>
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
X-Complaints-To: abuse@supernews.com
Xref: archiver1.google.com comp.lang.ada:41093
Date: 2003-07-31T12:31:29-05:00
List-Id: <comp.lang.ada>

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:7DbWa.1370$qN3.183518@news20.bellglobal.com...

> Agreed that the risk is lower, but it still exists if you place
> the objects (from a library) in the hands of a user.  If you
> are supporting that library, this increases risk of servicing
> calls that should not be your responsibility.

Why would a user be creating child units of the library? That seems dubious
in the first place.

Taking the example of Claw, if you declared a package like
Claw.Dialog.Foobar, you could get access to a lot of Claw internals. But the
only reason for a user to declare such a package is that they needed such
access (hopefully, they're building a new reusable component). In which
case, more hiding is not going to help.

Certainly, anyone who just "with"s Claw.Dialog is not going to get any
private stuff. And, in our experience with a large library given to the
general public, people aren't declaring (grand)children of Claw just so they
can fiddle around with stuff that they don't need. Especially as we spend a
lot of effort keeping the public interfaces stable, but we certainly say
nothing about private stuff. So I view this as a non-problem, especially as
techniques exist to avoid it.

If your users are randomly declaring children, their project has serious
project management problems. It's unlikely that the language can fix these
(or should try).

                Randy.