Re: Object Oreinted Style

[Dale Stanbrough <dale@cs.rmit.edu.au>]

Magnus Larsson wrote:

> In article <dale-617BD4.22171828032000@news.rmit.edu.au>,
> Dale Stanbrough <dale@cs.rmit.edu.au> wrote:
> [.....]
> >
> > Def. child packages "open up" the full view of a parent type declared
> > in a parent package, and in this regard invite abuse by preventing
> > total encapsulation.
> I am by no means an expert in this area, but isn't a "private package"
> a solution here?
> like :
> package Parent is
> type Base_Type is....
> ...
> end Parent;
> private package Parent.Child is
> type Derived_type is new Base_type.....
> ...
> end Parent.Child;
> Or have i completly missed the point here? I thought this construct does
> exactly this and "closes" any direct access to the child.


A private package can still see the full declaration of the type
defined in the parent package. This is what i meant by the private
type being "opened up" again (this is terminology borrowed from
Betrand Meyer really).

For example...

   package Parent is...

      type Base_Type is tagged private;
   private
      type Base_Type is tagged
         record
            X : integer;
         end record;
   end Parent;


   package Parent.Child is
      type Derived_Type is new Base_Type with private;

      procedure Clear_All_Fields (Item : Derived_Type);

   private
       etc.
   end;

In the body of Parent.Child procedure Clear_All_Fields can
change the value of the field X, despite it being declared 
private. Making Parent.Child doesn't prevent this from
happening.


Private packages are useful, but only to an extent. They prevent
compilation coupling (changing a private packages spec will never
require the recompilation of a package outside of the hierachy),
but fail to provide the sort of support for abstractions that i'ld
like to see (the completion of a private type in a public package
being derived from a type declared in a private package). I find
them frustratingly limiting for this reason.
Of course this is in constrast to "private" types inside packages, 
which do not prevent compilation coupling, but are used to support
abstractions!


Dale

Dale