Re: Record type with check?

[mark_lundquist@my-deja.com]

In article <93ikth$ik5$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <87hf373l3a.fsf@moon.mteege.de>,
>   Matthias Teege <matthias@mteege.de> wrote:
> > If nobody knows a
> > better representation I'll made a private type. ;-)
>
> A private type *IS* a better representation. Nearly all types
> should be private if they are at all complex, and most
> certainly if invariants like this are to be preserved, the
> appropriate interface is an abstract data type.

Matthias, don't say "I'll make it private if I have to", say "I'll make
it _public_ only if I have to!"

The full heuristic is something like this:

   1) Don't assume all type definitions belong in a package spec.

      Before putting a type in a spec, consider whether it might
      really belong in the body.  That's the essence of the advice
      in Nick Roberts' post (one way to look at it anyway --
      another is "think abstraction first, representation second").

      This is not at all to say it's categorically more desirable
      for type definitions to be in a body.  Just think about it,
      that's all.  If the essence of the abstraction is that clients
      declare instances of it, then it belongs in the spec; if it's
      needed to implement something within the body, put it in
      the body.  (You wouldn't, for instance, decide to use an "opaque
      handle" idiom for everything, just to keep types out of
      specs...)

   2) If the type belongs in the spec, it should go in the private
      part unless you have a reason for it to be public...

      Now if it's private, there are two ways to have better control
      over the abstraction:

      2a) Make the public view limited.

          Then clients cannot do assignment of instances of the type.
          You control whether they can test for equality (because you
          have to provide "="), and you control whether/how copies are
          made (since there's no assignment, copying would have to be
          by a subprogram that you provide).

          (Another way to control copying is to derive privately from
          Ada.Finalization.Controlled and override Adjust...)

      2b) Declare the public view with unknown discriminants, e.g.

              type Foo_Type (<>) is private;

          Then, whether the full view actually has discriminants or
          not, the only way for the client to declare an object of the
          type is with an initialization expression (because the client'
          has no other way to constrain the object!).  In your package,
          you can declare "constructor" functions that return an
          instance of the type, initialized correctly, and perform any
          side-effects associated with creation of the object.  The
          only way a client can create an object is to call one of your
          Create functions, E.g.,

              X : Foo.Foo_Type; -- Illegal!  Must be constrained...

              -- This works:
              --
              X : Foo.Foo_Type := Foo.Create (-- blah, blah, blah..);

          (Another way to control initialization is to derive privately
          from type Controlled or Limited_Controlled in
          Ada.Finalization and override Initialize, but that only gets
          you a "default constructor", i.e. with no parameters).

          If you make the public view limited *and* with unknown
          discriminants, then the client can't declare an instance
          of the type at all!  It can only set up functional
          "plumbing", because your package owns all the instances.

   3) If none of the above can work, then you know you have a type
      whose full view belongs in the public part of the spec! :-)

Have fun!

Mark Lundquist
Rational Software


Sent via Deja.com
http://www.deja.com/