Import is not inheritance - why we need both: Modules and classes (1992)
| Citations: | 50 - 2 self |
BibTeX
@INPROCEEDINGS{Szyperski92importis,
author = {Clemens A. Szyperski},
title = {Import is not inheritance - why we need both: Modules and classes},
booktitle = {},
year = {1992},
pages = {pages},
publisher = {Springer-Verlag}
}
Years of Citing Articles
Bookmark
 |
 |
 |
 |
 |
 |
OpenURL
Abstract
Abstract. The design of many popular object-oriented languages like Smalltalk, Eiffel, or Sather follows a certain trend: The class is the only structuring form. In this paper, the need for having modules besides classes is claimed. Modules stem from a different language family and at first glance it seems that they can easily be unified with classes. Among other things, unifying modules and classes carries the danger of unifying the import and inheritance relationships. Constructs in several languages are discussed that indicate that modules and classes should indeed be kept separate. 1 Introduction and Clarification of Terms Among other things, the quality of a programming language may be judged by the number, orthogonality, and completeness of its concepts. The first measure is as simple as counting; the second and third are far more difficult to determine. Orthogonality is important to avoid confusion; concept overlaps should at least be kept small. In practice, completeness is a
