Re: Proposal: Abstract types for OOC

[Stewart Greenhill <greenhil@murdoch.edu.au>]

At 06:06 PM 27/12/98 +0100, you wrote:
>Stewart Greenhill (greenhil@murdoch.edu.au) schrieb:
>
> >  a* = RECORD [ABSTRACT]
> >    x-, y- : REAL;
> >  END;
> >
> >  PROCEDURE [ABSTRACT] (VAR v : a) F * (x, y : REAL);
> >  BEGIN
> >  END F;
>
>After cross-reading you proposal, I still don't know whether the ABSTRACT
>keyword for Records is required or not.
>
>If it is: what should it be good for? For documentation purposes? Then it's
>not consistent with the language, since eg. methods are not "documented" when
>there class record is defined.

It is true that the compiler knows whether a type is abstract or not. By
definition, it is abstract if it has abstract methods. However, for a
programmer to determine this  he or she would have to scan the module in
which the type is defined, as well as the modules of all super-types to
search for abstract methods. In this sense, the ABSTRACT system flag
enforces a simple documentation convention: all abstract types must be
declared to be abstract.

More importantly, the ABSTRACT system flag signals the programmers
intention to the compiler. It unambiguously distinguishes between abstract
and concrete types. Without this distinction, the compiler would have to
assume that any type with abstract methods is abstract. This may not agree
with the programmers intentions (eg. they intended to declare a concrete
type, but forgot to implement an abstract method). The ABSTRACT flag on
records allows us to catch this kind of error. If a record declared without
the ABSTRACT flag, the compiler knows that a concrete type is being
declared and that any inherited abstract methods MUST be implemented by the
programmer. The compiler can therefore signal an error for each abstract
method that the programmer has not implemented. I see this as an important
safety feature.

>Should it be possible -- acording to your proposal -- to define an abstract
>record without any abstract methods? (This would be the only case I can
>imagine where _declaring_ a _record_ as being abstract. This is: using
>RECORD ... ABSTRACT.) What is the "abstract" part of this? 

Yes. By my proposal, you can declare abstract records without any abstract
methods. Technically, this goes against my original definition of abstract
types being those with abstract methods. Thus, we should probably either
change the definition, or disallow this kind of declaration.

A record declared ABSTRACT without abstract methods implies that:

1) It can have abstract extensions, so sub-types can introduce new abstract
methods. This cannot be done for concrete types.

2) It cannot be instantiated. Thus, the programmer must declare a concrete
extension.

I can't think of any situations where this would be particularly useful
properties for what are essentially "concrete" types. The primary purpose
of abstract types is to separate interfaces from implementation. This does
not occur if an "abstract" type has only concrete methods. Likewise, this
separation does not occur if an "abstract" type specifies only structure
and has no methods at all.

We could enforce this interpretation of abstract types by insisting that
every type declared ABSTRACT has at least one method declared ABSTRACT. I
would be prepared to add this to the specification. Can anyone think of any
useful programming constructs that would be disallowed by this restriction? 

>What determines
>whether an extension of this type is abstract or concrete?

By the proposal, an extension is concrete unless it is delcared with the
ABSTRACT flag.

>+++hartmut

- Stewart