1100 EMULATING OBJECT TECHNOLOGY IN NON-O-O ENVIRONMENTS $34.2 Then we find object-oriented languages.This is not the place to be fussy about what exactly it takes to deserve this label-chapter 2 defined a set of criteria,and of course all of part C was devoted to analyzing O-O mechanisms in detail-,but we should at the very least expect some support for classes,inheritance,polymorphism and dynamic binding. For the second category,encapsulation languages,which supports a data See[Wegner1987刃 abstraction mechanism but no classes,inheritance,polymorphism or dynamic binding,you will find that the literature commonly uses the term object- based,introduced in an article by Peter Wegner.Because the English words based and oriented do not readily evoke the conceptual difference between encapsulation techniques and O-O languages,"object-based"is a little hard to justify,especially to newcomers.Although either terminology is acceptable once you have defined the conventions,I have in the end decided to stick here to the phrases "encapsulation languages"and"object-oriented languages", which more clearly conjure up the conceptual difference. While we are on the subject of terminology:the term "functional language"is ambiguous since other parts of the literature apply it to a class of languages,based on mathematical principles and often deriving directly or indirectly from Lisp,which use side-effect-free functions instead of imperative constructs such as procedures and assignments.To avoid any confusion,the present book always uses the term applicative to denote this programming style.The word function in our use of"functional language" is to be contrasted with object,not (as when "functional"is a synonym for "applicative") with procedure.(To make a confusing situation worse,it is quite common to see "procedural"taken to mean "not object-oriented"!There is,however,no basis for such terminology,“procedural'”normally means“imperative'”,as opposed to applicative,:all the common O-O languages,including the notation of this book,are quite procedural.) A general comment on O-O emulation.In its most basic form,object technology is "programming with abstract data types".You can apply a rudimentary form of the ideas, even at the functional level,by defining a set of strict methodological guidelines requiring every data access to go through routines.This assumes that you start from an object- oriented design that has defined ADTs and their features;then you will write a set of routines representing these features-put,remove,item,empty in our standard stack example-and require all client modules to go through these routines.This is a far cry from object technology proper,and can only work under the assumption that everyone in the team behaves;but,if you lack any kind of language support,it can be a start.We will call this technique the disciplinary approach. 34.2 OBJECT-ORIENTED PROGRAMMING IN PASCAL? Pascal,introduced in 1970 by Niklaus Wirth,has been for many years the dominant language for teaching introductory programming in computing science departments,and has influenced many of the subsequent language designs.Pascal is definitely a functional language in the sense just defined.1100 EMULATING OBJECT TECHNOLOGY IN NON-O-O ENVIRONMENTS §34.2 • Then we find object-oriented languages. This is not the place to be fussy about what exactly it takes to deserve this label — chapter 2 defined a set of criteria, and of course all of part C was devoted to analyzing O-O mechanisms in detail —, but we should at the very least expect some support for classes, inheritance, polymorphism and dynamic binding. For the second category, encapsulation languages, which supports a data abstraction mechanism but no classes, inheritance, polymorphism or dynamic binding, you will find that the literature commonly uses the term object￾based, introduced in an article by Peter Wegner. Because the English words based and oriented do not readily evoke the conceptual difference between encapsulation techniques and O-O languages, “object-based” is a little hard to justify, especially to newcomers. Although either terminology is acceptable once you have defined the conventions, I have in the end decided to stick here to the phrases “encapsulation languages” and “object-oriented languages”, which more clearly conjure up the conceptual difference. While we are on the subject of terminology: the term “functional language” is ambiguous since other parts of the literature apply it to a class of languages, based on mathematical principles and often deriving directly or indirectly from Lisp, which use side-effect-free functions instead of imperative constructs such as procedures and assignments. To avoid any confusion, the present book always uses the term applicative to denote this programming style. The word function in our use of “functional language” is to be contrasted with object, not (as when “functional” is a synonym for “applicative”) with procedure. (To make a confusing situation worse, it is quite common to see “procedural” taken to mean “not object-oriented”! There is, however, no basis for such terminology; “procedural” normally means “imperative”, as opposed to applicative; all the common O-O languages, including the notation of this book, are quite procedural.) A general comment on O-O emulation. In its most basic form, object technology is “programming with abstract data types”. You can apply a rudimentary form of the ideas, even at the functional level, by defining a set of strict methodological guidelines requiring every data access to go through routines. This assumes that you start from an object￾oriented design that has defined ADTs and their features; then you will write a set of routines representing these features — put, remove, item, empty in our standard stack example — and require all client modules to go through these routines. This is a far cry from object technology proper, and can only work under the assumption that everyone in the team behaves; but, if you lack any kind of language support, it can be a start. We will call this technique the disciplinary approach. 34.2 OBJECT-ORIENTED PROGRAMMING IN PASCAL? Pascal, introduced in 1970 by Niklaus Wirth, has been for many years the dominant language for teaching introductory programming in computing science departments, and has influenced many of the subsequent language designs. Pascal is definitely a functional language in the sense just defined. See [Wegner 1987]