TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Robert I. Eachus" <[log in to unmask]>
Reply To:
Robert I. Eachus
Date:
Wed, 15 Apr 1998 13:15:29 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (29 lines)
At 10:47 PM 4/14/98 +1000, Alan E & Carmel J Brain wrote:
>What about the use of renaming to package ( a subset of resources of )
>other packages into one logically related chunk?
>Is this a sign of good structure? HECK NO! But if you're re-using
>components, it may be that re-structuring is a luxury you can't afford.
>
>I've not seen this used much, but when it was, it was relatively
>innocuous, and hid a lot of relatively dangerous resources in the specs.
>Yet it seems anathema to me, a sign of bad design.

   I gave this sort of construct the name "Unchecked Perversion" because
the first and worst example I saw had an instance of Unchecked_Conversion
in the public part of the package specification.  But the error is not in
using the language to build more useful abstractions.  It is taking the "it
will work for me" shortcut (which on most compilers only saves keyboarding)
of putting things that belong in the private part of a package or in the
body in the visible part instead.  Now code all over the program can have
undocumented dependencies between (otherwise) unrelated types.  (The case
that provided the name tied System.Address to C style strings.)

    So the idea isn't bad, but the implementation shouldn't be visible to
the user of the abstraction.

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

ATOM RSS1 RSS2