35 Simula to Java and beyond:major O-O languages and environments ncouraged by the introduction of Simula in17anumber of obectrend languages have appeared on the scene,highlighting various aspects of the approach.This chapter reviews some of the languages that have attracted the most attention:Simula; Smalltalk;C++and other O-O extensions of C;Java. The literature still lacks an in-depth comparative study of important O-O languages. The ambition of this chapter is of necessity more modest.In particular,the space allotted to each language is not an indication of the language's practical significance,and some of the most publicized will indeed get a fairly short treatment.Our goal is to learn about issues and concepts,finding them where we can,even if that means turning our attention for a while to one of the less hyped approaches.The risk of under-representing one of the principal players is not great,since one only has to look around to pick up articles and books describing it in generous detail.The real risk would be the reverse:to miss a promising idea just because the language supporting it(say Simula)does not currently enjoy top favor.In its coverage of notable languages,then,this survey is not equal-opportunity;it is instead, in its choice of notable language traits,a case of affirmative action. Even when the concepts are the same or similar,the terms used to denote them in official language descriptions can vary.The discussion will use the native terms when they reflect language peculiarities;for simplicity and consistency,however,it uses the terminology of the rest of this book (designed as an attempt at unification)when differences are unimportant.For example you will read about Simula routines,procedures and functions,although the corresponding terms in official Simula usage are procedure, unty ped procedure and typed procedure. 35.1 SIMULA The undisputed founder of the House of Classes (Object Palace)is Simula,whose design was completed(if we ignore a few later updates,entirely minor)in 1967.This may seem hard to believe:a full-fledged object-oriented language was around,and implemented, before structured programming,before Parnas had published his articles on information hiding,many years before anyone had come up with the phrase"abstract data type".The Vietnam War was still a page-4 item;barricades had not yet sprung up in the streets of Paris;a mini-skirt could still cause a stir:away by the Northern shores of the Baltic a few
35 Simula to Java and beyond: major O-O languages and environments Encouraged by the introduction of Simula in 1967, a number of object-oriented languages have appeared on the scene, highlighting various aspects of the approach. This chapter reviews some of the languages that have attracted the most attention: Simula; Smalltalk; C++ and other O-O extensions of C; Java. The literature still lacks an in-depth comparative study of important O-O languages. The ambition of this chapter is of necessity more modest. In particular, the space allotted to each language is not an indication of the language’s practical significance, and some of the most publicized will indeed get a fairly short treatment. Our goal is to learn about issues and concepts, finding them where we can, even if that means turning our attention for a while to one of the less hyped approaches. The risk of under-representing one of the principal players is not great, since one only has to look around to pick up articles and books describing it in generous detail. The real risk would be the reverse: to miss a promising idea just because the language supporting it (say Simula) does not currently enjoy top favor. In its coverage of notable languages, then, this survey is not equal-opportunity; it is instead, in its choice of notable language traits, a case of affirmative action. Even when the concepts are the same or similar, the terms used to denote them in official language descriptions can vary. The discussion will use the native terms when they reflect language peculiarities; for simplicity and consistency, however, it uses the terminology of the rest of this book (designed as an attempt at unification) when differences are unimportant. For example you will read about Simula routines, procedures and functions, although the corresponding terms in official Simula usage are procedure, untyped procedure and typed procedure. 35.1 SIMULA The undisputed founder of the House of Classes (Object Palace) is Simula, whose design was completed (if we ignore a few later updates, entirely minor) in 1967. This may seem hard to believe: a full-fledged object-oriented language was around, and implemented, before structured programming, before Parnas had published his articles on information hiding, many years before anyone had come up with the phrase “abstract data type”. The Vietnam War was still a page-4 item; barricades had not yet sprung up in the streets of Paris; a mini-skirt could still cause a stir: away by the Northern shores of the Baltic a few
1114 SIMULA TO JAVA AND BEYOND:MAJOR O-O LANGUAGES AND ENVIRONMENTS $35.1 fortunate software developers led by a handful of visionaries were already profiting from the power of classes,inheritance,polymorphism,dynamic binding and most of the other marvels of object orientation. Background Simula is actually a second design.In the early sixties,a language now known as Simula I was developed to support the programming of discrete-event simulations.Although not quite object-oriented in the full sense of the term,it already showed some of the key insights."Simula"proper is Simula 67,designed in 1967 by Kristen Nygaard and Ole- Johan Dahl from the University of Oslo and the Norwegian Computing Center (Norsk Regnesentral).Nygaard has explained since how the decision to keep the name was meant to ensure continuity with the previous language and the link to its user community;but an unfortunate effect was that for a long time that name evoked for many people the image of a language meant only for discrete-event simulation-a relatively narrow application area-even though Simula 67 is definitely a general-purpose programming language, whose only simulation-specific features are a handful of instructions and a S/MUL4T/ON library class,used by a minority of Simula developers. The name was shortened to just Simula in 1986;the current standard is from 1987. Availability Simula is often presented as a respectable but defunct ancestor.In fact it is still alive and enjoys the support of a small but enthusiastic community.The language definition is maintained by the "Simula Standards Group".Compilers are available for a variety of hardware and software environments from several companies,mostly Scandinavian. Major language traits We will take a general look at the basic properties of Simula.To some readers Simula will be passe,and the author of this book will not feel insulted if you skip to the next section, on Smalltalk.But if you do want to gain a full appreciation of object technology you will find Simula worth your time;the concepts are there in their original form,and a few of them show possibilities that may not yet,thirty years later,have been fully exploited. Simula is an object-oriented extension of Algol 60.Most correct Algol programs are also correct Simula programs.In particular,the basic control structures are those of Algol: loop,conditional,switch(a multiple branch instruction,low-level precursor to Pascal's case instruction).The basic data types(integer,real etc.)are also drawn from Algol. Like Algol,Simula uses at the highest level a traditional software structure based on the notion of main program.An executable program is a main program containing a number of program units (routines or classes).Simula environments do support,however, a form of separate class compilation. Simula uses full block structure in the Algol 60 style:program units such as classes may be nested within one another
1114 SIMULA TO JAVA AND BEYOND: MAJOR O-O LANGUAGES AND ENVIRONMENTS §35.1 fortunate software developers led by a handful of visionaries were already profiting from the power of classes, inheritance, polymorphism, dynamic binding and most of the other marvels of object orientation. Background Simula is actually a second design. In the early sixties, a language now known as Simula 1 was developed to support the programming of discrete-event simulations. Although not quite object-oriented in the full sense of the term, it already showed some of the key insights. “Simula” proper is Simula 67, designed in 1967 by Kristen Nygaard and OleJohan Dahl from the University of Oslo and the Norwegian Computing Center (Norsk Regnesentral). Nygaard has explained since how the decision to keep the name was meant to ensure continuity with the previous language and the link to its user community; but an unfortunate effect was that for a long time that name evoked for many people the image of a language meant only for discrete-event simulation — a relatively narrow application area — even though Simula 67 is definitely a general-purpose programming language, whose only simulation-specific features are a handful of instructions and a SIMULATION library class, used by a minority of Simula developers. The name was shortened to just Simula in 1986; the current standard is from 1987. Availability Simula is often presented as a respectable but defunct ancestor. In fact it is still alive and enjoys the support of a small but enthusiastic community. The language definition is maintained by the “Simula Standards Group”. Compilers are available for a variety of hardware and software environments from several companies, mostly Scandinavian. Major language traits We will take a general look at the basic properties of Simula. To some readers Simula will be passé, and the author of this book will not feel insulted if you skip to the next section, on Smalltalk. But if you do want to gain a full appreciation of object technology you will find Simula worth your time; the concepts are there in their original form, and a few of them show possibilities that may not yet, thirty years later, have been fully exploited. Simula is an object-oriented extension of Algol 60. Most correct Algol programs are also correct Simula programs. In particular, the basic control structures are those of Algol: loop, conditional, switch (a multiple branch instruction, low-level precursor to Pascal’s case instruction). The basic data types (integer, real etc.) are also drawn from Algol. Like Algol, Simula uses at the highest level a traditional software structure based on the notion of main program. An executable program is a main program containing a number of program units (routines or classes). Simula environments do support, however, a form of separate class compilation. Simula uses full block structure in the Algol 60 style: program units such as classes may be nested within one another
$35.1 SIMULA 1115 All Simula implementations support automatic garbage collection.There is a small standard library,including in particular two-way linked lists used by the S/MULATION class studied later in this chapter. See“References and As in the notation of this book,the most common entities of non-basic types denote simple values", references to class instances,rather than the instances themselves.Instead of being page 272. implicit,however,this property is emphasized by the notation.You will declare the type of such an entity as ref(C),rather than just C,for some class C;and the corresponding operations will use special symbols::-for an assignment where integer or real operands would use:=;==rather than for equality;=/rather than /for inequality.An earlier chapter presented the rationale for and against this convention. To create an instance,you will use,rather than a creation instruction,a new expression: ref(C)a;...a:-new C Evaluation of the new expression creates an instance of C and returns a reference to it.A class may have arguments(playing the role of the arguments to creation procedures in our notation),as in class C(x,y);integer x,y begin ..end: In this case,the new expression must provide corresponding actual arguments: a:-new C(3,98) The arguments may then be used in routines of the class;but unlike with creation instructions this gives only one initialization mechanism. Besides routines and attributes,a class may contain a sequence of instructions,the body of the class;if so,the new call will execute these instructions.We will see how to use this possibility to make classes represents process-like computational elements rather than just passive objects as in most other O-O languages. No assertion mechanism is provided.Simula supports single inheritance;to declare B as an heir of 4,use A class B: begin...end To redefine a feature of a class in a descendant class,simply provide a new declaration;it will take precedence over the original one.(There is no equivalent to the redefine clause.) The original version of Simula 67 did not have explicit information hiding constructs.In more recent versions,a feature declared as protected will be unavailable to clients;a protected feature which is further declared as hidden will also be unavailable to proper descendants.A non-protected feature may be protected by a proper descendant,but a protected feature may not be re-exported by proper descendants
§35.1 SIMULA 1115 All Simula implementations support automatic garbage collection. There is a small standard library, including in particular two-way linked lists used by the SIMULATION class studied later in this chapter. As in the notation of this book, the most common entities of non-basic types denote references to class instances, rather than the instances themselves. Instead of being implicit, however, this property is emphasized by the notation. You will declare the type of such an entity as ref (C), rather than just C, for some class C; and the corresponding operations will use special symbols: :– for an assignment where integer or real operands would use :=; == rather than = for equality; =/= rather than /= for inequality. An earlier chapter presented the rationale for and against this convention. To create an instance, you will use, rather than a creation instruction, a new expression: ref (C) a; …; a :– new C Evaluation of the new expression creates an instance of C and returns a reference to it. A class may have arguments (playing the role of the arguments to creation procedures in our notation), as in class C (x, y); integer x, y begin … end; In this case, the new expression must provide corresponding actual arguments: a :– new C (3, 98) The arguments may then be used in routines of the class; but unlike with creation instructions this gives only one initialization mechanism. Besides routines and attributes, a class may contain a sequence of instructions, the body of the class; if so, the new call will execute these instructions. We will see how to use this possibility to make classes represents process-like computational elements rather than just passive objects as in most other O-O languages. No assertion mechanism is provided. Simula supports single inheritance; to declare B as an heir of A, use A class B; begin … end To redefine a feature of a class in a descendant class, simply provide a new declaration; it will take precedence over the original one. (There is no equivalent to the redefine clause.) The original version of Simula 67 did not have explicit information hiding constructs. In more recent versions, a feature declared as protected will be unavailable to clients; a protected feature which is further declared as hidden will also be unavailable to proper descendants. A non-protected feature may be protected by a proper descendant, but a protected feature may not be re-exported by proper descendants. See “References and simple values”, page 272
1116 SIMULA TO JAVA AND BEYOND:MAJOR O-O LANGUAGES AND ENVIRONMENTS $35.1 Deferred features are offered in the form of"virtual routines",appearing in a virtual paragraph at the beginning of the class.It is not necessary to declare the arguments of a virtual routine;this means that different effective definitions ofa virtual routine may have different numbers and types of arguments.For example,a class POLYGON might begin class POLYGON; virtual:procedure set_vertices begin 4+ end allowing descendants to provide a variable number of arguments of type POINT for set vertices:three for TR/ANGLE,four for OUADRANGLE etc.This flexibility implies that some of the type checking must be done at run time. C++users should beware of a possible confusion:although inspired by Simula,C++uses “TheC++ a different meaning for the word virtual.A C++function is virtual if it is meant to be approach to bind- dynamically bound (it is,as we have seen,one of the most controversial aspects of C++ ing",page 514. that you must specify this requirement explicitly).The C++approximation to Simula's virtual procedures is called a"pure virtual function" Simula supports polymorphism:if B is a descendant of,the assignmental-b/is correct for al of type A and b/of type B.(Interestingly enough,assignment attempt is almost there:if the type of b/is an ancestor of the type of al,the assignment will work if the run-time objects have the proper conformance relationship-source descendant of target,if not,however,the result will be a run-time error,rather than a special value which, as with assignment attempt,the software could detect and handle.)By default,binding is static rather than dynamic,except for virtual routines.So if/is a non-virtual feature declared at the 4 level,al.f will denote the 4 version of/even if there is a different version in B.You can force dynamic binding by using the qua construct,as in (al qua B).f This,of course,loses the automatic adaptation of every operation to its target.You may however obtain the desired dynamic binding behavior (which may largely be considered a Simula invention)by declaring polymorphic routines as virtual.In many of the examples that we have studied,a polymorphic routine was not deferred but had a default implementation right from the start.To achieve the same effect,the Simula developer will add an intermediate class where the routine is virtual. As an alternative to using qua,the inspeet instruction makes it possible to perform a different operation on an entity a/,depending on the actual type of the corresponding object,which must be a descendant of the type 4 declared for al: inspect al when 4 do ... when B do...; This achieves the same effect but assumes that the set of descendants of a class is frozen,and runs into conflict with the Open-Closed principle
1116 SIMULA TO JAVA AND BEYOND: MAJOR O-O LANGUAGES AND ENVIRONMENTS §35.1 Deferred features are offered in the form of “virtual routines”, appearing in a virtual paragraph at the beginning of the class. It is not necessary to declare the arguments of a virtual routine; this means that different effective definitions of a virtual routine may have different numbers and types of arguments. For example, a class POLYGON might begin class POLYGON; virtual: procedure set_vertices begin … end allowing descendants to provide a variable number of arguments of type POINT for set_vertices: three for TRIANGLE, four for QUADRANGLE etc. This flexibility implies that some of the type checking must be done at run time. C++ users should beware of a possible confusion: although inspired by Simula, C++ uses a different meaning for the word virtual. A C++ function is virtual if it is meant to be dynamically bound (it is, as we have seen, one of the most controversial aspects of C++ that you must specify this requirement explicitly). The C++ approximation to Simula’s virtual procedures is called a “pure virtual function”. Simula supports polymorphism: if B is a descendant of A, the assignment a1 :– b1 is correct for a1 of type A and b1 of type B. (Interestingly enough, assignment attempt is almost there: if the type of b1 is an ancestor of the type of a1, the assignment will work if the run-time objects have the proper conformance relationship — source descendant of target; if not, however, the result will be a run-time error, rather than a special value which, as with assignment attempt, the software could detect and handle.) By default, binding is static rather than dynamic, except for virtual routines. So if f is a non-virtual feature declared at the A level, a1 ● f will denote the A version of f even if there is a different version in B. You can force dynamic binding by using the qua construct, as in (a1 qua B) ● f This, of course, loses the automatic adaptation of every operation to its target. You may however obtain the desired dynamic binding behavior (which may largely be considered a Simula invention) by declaring polymorphic routines as virtual. In many of the examples that we have studied, a polymorphic routine was not deferred but had a default implementation right from the start. To achieve the same effect, the Simula developer will add an intermediate class where the routine is virtual. As an alternative to using qua, the inspect instruction makes it possible to perform a different operation on an entity a1, depending on the actual type of the corresponding object, which must be a descendant of the type A declared for a1: inspect a1 when A do …; when B do …; … This achieves the same effect but assumes that the set of descendants of a class is frozen, and runs into conflict with the Open-Closed principle “The C++ approach to binding”, page 514
§35.1 SIMULA 1117 An example Chapter 20.Com- The following class extracts illustrate the general flavor of Simula.They are drawn from pare with the final the solution to the problem of full-screen entry systems. class texts in“AW OBJECT-ORI- class STATE: ENTED ARCHI TECTURE”20.5, virtual: page 684. procedure display; The original STATE procedure read; class appeared on page 686. boolean procedure correct; procedure message; procedure process; begin ref (ANSWER)user_answer;integer choice, procedure execute;begin boolean ok; ok :false: while not ok do begin display;read;ok :correct, if not ok then message (a) end while; process. end execute end STATE; The original APLI- class APPLICATION (n,m); CATION class integer n,m; appeared on page 690. begin ref (STATE)array transition (I:n,0:m-1); ref (STATE)array associated state (1:n). integer initial; procedure execute;begin integer st number; st number:=initial; while st number =0 do begin ref (STATE)st. st associated state (st number),st.execute; st number transition (st number,st.choice) end while end execute end APPLICATION
§35.1 SIMULA 1117 An example The following class extracts illustrate the general flavor of Simula. They are drawn from the solution to the problem of full-screen entry systems. class STATE; virtual: procedure display; procedure read; boolean procedure correct; procedure message; procedure process; begin ref (ANSWER) user_answer; integer choice; procedure execute; begin boolean ok; ok := false; while not ok do begin display; read; ok := correct; if not ok then message (a) end while; process; end execute end STATE; class APPLICATION (n, m); integer n, m; begin ref (STATE) array transition (1:n, 0:m–1); ref (STATE) array associated_state (1:n); integer initial; procedure execute; begin integer st_number; st_number := initial; while st_number /= 0 do begin ref (STATE) st; st := associated_state (st_number); st ● execute; st_number := transition (st_number, st ● choice) end while end execute … end APPLICATION Chapter 20. Compare with the final class texts in “AN OBJECT-ORIENTED ARCHITECTURE”, 20.5, page 684. The original STATE class appeared on page 686. The original APLICATION class appeared on page 690