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
function Message (Text: in Clever_Ideas) return Better_Ideas is...