Re: Proposal: Abstract types for OOC

[hartmut Goebel <hartmut@oberon.noris.de>]

Stewart Greenhill (greenhil@murdoch.edu.au) schrieb:

To say it first: I dislike the ABSTRACT keyword at the type declaration
point. It's unneccessary, confusing, problematic. See the following reasoning
for details. For thos not interessted in the details, read the conclusion
at the end of this text.

 >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.

According to this arguments: would you suggest enforcing the declaration of
methods when declarating the record? If yes: This is no longer Oberon then.
If No: Why then require a record to be declared abstract?

 >In this sense, the ABSTRACT system flag
 >enforces a simple documentation convention: all abstract types must be
 >declared to be abstract.

You may use a tool for that. Its names 'browser' :-)

 >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.

Is it really necessary to catch this error? I don't think so!

Simple ecample:
Module "Abstract" defined an abstract record + methods.
Module "Concrete" implement a concrete type base on Abstract.
Moduel "UseConcrete" instantiates this concrete type.

The only benefit in this case would be: the error get signaled when compiling
"Concrete".

Whithout explicit declaring records as abstract, the compilation of
"UseConcrete" would signal an error.

 >I see this as an important
 >safety feature.

It's a safety feature, but not at all important.

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

But this is pretty usefull, eg.:

  File = RECORD ... END;  (* concrete *)
  CompressedFile = RECORD ... END;
  PROC ABSRACT Compress * (cf: CompressedFile); END Compress;

This enables to extent types for things, the author of the base class hadn't
thought about. According to your proposal, this would not be possible -- thus
limiting the usability.

This may leed to all record type being declared as abstract. See below about
this problem.

 >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.

Changing the definition of "abstract type" is no solution. What is "abstract"
on this type:

  Module XX;
  TYPE
    X = RECORD ABSTRACT
          a,b: INTEGER;
        END;
  END XX.

Beside of being declared as abstract, it is concrete. Wiered, isn't it?

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

What speaks again instantiating the above type XX.X?

 >I can't think of any situations where this would be particularly useful
 >properties for what are essentially "concrete" types.

So why not disallow declaration of thus type at all? By simply ommitting the
ASTRACT keyword for record type declarations.

 >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?

Since one can not re-abstract a concrete type (according to your proposal),
one has to declare each type (eg. "Object") to-be-extented-somewhen as
abstract. This would lead to nearly all type being declared as abstract.

But since I can't implement all methods of "Object", I can't declare it as
abstract -- thus it's concrete, thus it can't be re-abstracted later.


Conclusion
----------

Requiering of explicit declaring a record type as abstract introduces a lot
of problems, be it logically, language consistency, extensability or
implementational (see mva's posting).

The only benefits are 1) documentation and 2) early error catching.

These benefits re over-weight by the drawbacks. Thus I "vote" against this
part of the proposal!

 >- Stewart

+++hartmut