Import is not inheritance - why we need both: Modules and classes

Import is not inheritance - why we need both: Modules and classes (1992)

by Clemens A. Szyperski

Citations:

50 - 2 self

Datum	Value	Source
TITLE	Import is not inheritance - why we need both: Modules and classes	INFERENCE
AUTHOR NAME	Clemens A. Szyperski	SVM HeaderParse 0.2
AUTHOR AFFIL	Institute for Computer Systems; Swiss Federal Institute of Technology (ETH Zurich)	SVM HeaderParse 0.2
AUTHOR ADDR	Switzerland	SVM HeaderParse 0.2
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	SVM HeaderParse 0.2
YEAR	1992	INFERENCE
VENUE TYPE	CONFERENCE	INFERENCE
PAGES	pages	INFERENCE
VOLUME	615	INFERENCE
CITATIONS	32 found	ParsCit 1.0