444 MORE O-O MECHANISMS $13.2 The non-O-O mechanisms are still present,often in apparent competition with their higher-level object-oriented counterparts.For example C++offers,along with dynamic binding,the ability to choose a function at run time through arithmetic on function pointers.This is disconcerting for the non-expert who lacks guidance on which approach to choose in a particular case.The resulting software,although compiled by an O-O environment,is still,deep-down,C code,and does not yield the expected quality and productivity benefits-giving object technology a bad name through no fault of its own. If the aim is to obtain the best possible software process and products,compromising at the language level does not seem the right approach.Interfacing object-oriented tools and techniques with previous achievements is not the same thing as mixing widely different levels of technology. With the usual precautions about attaching too much weight to a metaphor,we can think of the precedent of electronics.It is definitely useful to combine different technology levels in a single system,as in an audio amplifier which still includes a few diodes together with transistors and integrated circuits.But the levels remain separate:there is little use for a basic component that would be half-diode,half-transistor. O-O development should provide compatibility with software built with other approaches,but not at the expense of the method's power and integrity.This is what the external mechanism achieves:separate worlds,each with its own consistency and benefits,and clear interfaces between these worlds 13.2 ARGUMENT PASSING One aspect of the notation may require some clarification:what may happen to values passed as arguments to routines? Consider a routine call of the form r (al a2....,an) corresponding to a routine r(xrTx2T,xmTm)is… where the routine could be a function as well as a procedure,and the call could be qualified,as in b.r(...).The expressions aj,a2,...,a are called actual arguments,and the x are called formal arguments.(Recall that we reserve the term "parameter"for generic type parameters.) The relevant questions are:what is the correspondence between actual and formal arguments?What operations are permitted on formal arguments?What effect will they have on the corresponding actuals?For all three we should stick to simple and safe rules. We already know the answer to the first question:the effect of actual-formal argument association is the same as that of a corresponding assignment.Both operations are called attachments.For the above call we can consider that the routine's execution starts by executing instructions informally equivalent to the assignments
444 MORE O-O MECHANISMS §13.2 • The non-O-O mechanisms are still present, often in apparent competition with their higher-level object-oriented counterparts. For example C++ offers, along with dynamic binding, the ability to choose a function at run time through arithmetic on function pointers. This is disconcerting for the non-expert who lacks guidance on which approach to choose in a particular case. The resulting software, although compiled by an O-O environment, is still, deep-down, C code, and does not yield the expected quality and productivity benefits — giving object technology a bad name through no fault of its own. If the aim is to obtain the best possible software process and products, compromising at the language level does not seem the right approach. Interfacing object-oriented tools and techniques with previous achievements is not the same thing as mixing widely different levels of technology. With the usual precautions about attaching too much weight to a metaphor, we can think of the precedent of electronics. It is definitely useful to combine different technology levels in a single system, as in an audio amplifier which still includes a few diodes together with transistors and integrated circuits. But the levels remain separate: there is little use for a basic component that would be half-diode, half-transistor. O-O development should provide compatibility with software built with other approaches, but not at the expense of the method’s power and integrity. This is what the external mechanism achieves: separate worlds, each with its own consistency and benefits, and clear interfaces between these worlds. 13.2 ARGUMENT PASSING One aspect of the notation may require some clarification: what may happen to values passed as arguments to routines? Consider a routine call of the form r (a1, a2, …, an) corresponding to a routine r (x1: T1, x2: T2, …, xn: Tn) is … where the routine could be a function as well as a procedure, and the call could be qualified, as in b ● r (…). The expressions a1, a2, …, an are called actual arguments, and the xi are called formal arguments. (Recall that we reserve the term “parameter” for generic type parameters.) The relevant questions are: what is the correspondence between actual and formal arguments? What operations are permitted on formal arguments? What effect will they have on the corresponding actuals? For all three we should stick to simple and safe rules. We already know the answer to the first question: the effect of actual-formal argument association is the same as that of a corresponding assignment. Both operations are called attachments. For the above call we can consider that the routine’s execution starts by executing instructions informally equivalent to the assignments
$13.2 ARGUMENT PASSING 445 x1=a5X2=a2…xm=am On the second question:within the routine body,any formal argumentx is protected. The routine may not apply to it any direct modification,such as: An assignment to x,of the formx=... A creation instruction with x as its target:!x.make (... Readers familiar with the passing mechanism known as call by value will note that the restriction is harsher here:with call by value,formals are initialized to actuals but may then be the target of arbitrary operations. “ATTACHMENT: The answer to the third question-what can the routine actually do to the actuals? REFERENCE AND -follows from the use of attachment to define the semantics ofactual-formal association VALUE SEMAN- TlCS”,&.&pag Attachment means copying either a reference or an object.As you will remember from the 261,in particular discussion of attachment,this depends on whether the types involved are expanded: table on page 264. For reference types (the more common case),argument passing will copy a reference,either void or attached to an object. For expanded types(which include in particular the basic types:INTEGER,REAL and the like),argument passing will actually copy an object. In the first case,the prohibition of direct modification operations means that you cannot modify the reference through reattachment or creation;but if the reference is not void you can modify the attached object through appropriate routines. Permissible The routine may not change this operations on a reference (e.g. reattach it to reference another object) argument The routine may change fields of this object (through calls to other Ifx,is one of the formal arguments to routine r,the body of the routine could contain a call of the form xp(.) where p is a procedure applicable tox,,meaning a procedure declared in the base class of x's type T.This routine may modify the fields of the object attached tox,at execution time,which is the object attached to the corresponding actual argument a
§13.2 ARGUMENT PASSING 445 x1 := a1; x2 := a2; … xn := an On the second question: within the routine body, any formal argument x is protected. The routine may not apply to it any direct modification, such as: • An assignment to x, of the form x := … • A creation instruction with x as its target: !! x ● make (…) Readers familiar with the passing mechanism known as call by value will note that the restriction is harsher here: with call by value, formals are initialized to actuals but may then be the target of arbitrary operations. The answer to the third question — what can the routine actually do to the actuals? — follows from the use of attachment to define the semantics of actual-formal association Attachment means copying either a reference or an object. As you will remember from the discussion of attachment, this depends on whether the types involved are expanded: • For reference types (the more common case), argument passing will copy a reference, either void or attached to an object. • For expanded types (which include in particular the basic types: INTEGER, REAL and the like), argument passing will actually copy an object. In the first case, the prohibition of direct modification operations means that you cannot modify the reference through reattachment or creation; but if the reference is not void you can modify the attached object through appropriate routines. If xi is one of the formal arguments to routine r, the body of the routine could contain a call of the form xi ● p (…) where p is a procedure applicable to xi , meaning a procedure declared in the base class of xi ’s type Ti . This routine may modify the fields of the object attached to xi at execution time, which is the object attached to the corresponding actual argument ai . “ATTACHMENT: REFERENCE AND VALUE SEMANTICS”, 8.8, page 261, in particular table on page 264. Permissible operations on a reference argument xi The routine may not change this reference (e.g. reattach it to another object) O1 The routine may change fields of this object (through calls to other
446 MORE O-O MECHANISMS $13.2 So although a call g(a)can never change the value of a-the corresponding object if a is expanded,the reference otherwise-it can,in the reference case,change the attached object. There are many reasons for not permitting routines to modify their arguments directly.One of the most striking is the Conflicting Assignments To Actual trick.Assume a language that permits assignments to arguments,and a procedure dont I look innocuous (a,b:INTEGER)is WARNING:invalid --But do not trust me too much. routine text.For pur- poses of illustration do only. a=0:b=1 end Then consider the call dont I look innocuous (x,x)for some entity x.What is the value ofx on return:0 or 1?The answer depends on how the compiler implements formal- to-actual update on routine exit.This has fooled more than a few Fortran programmers, among others. Permitting argument-modifying routines would also force us to impose restrictions On constant attrib- on actual arguments:the actual corresponding to a modifiable formal must be an element utes see chapter 18. that can change its value(a writable entity);this allows variable attributes,but not constant attributes,Current,or general expressions such as a +b.By precluding argument- modifying routines we can avoid imposing such restrictions and accept any expression as actual argument As a consequence of these rules,there are only three ways to modify the value of a reference x:through a creation instruction !x...;through an assignment x:=y;and through a variant of assignment,assignment attempt x ?=y,studied in a later chapter. Passingx as actual argument to a routine will never modify x. This also means that a routine returns at most one result:none if it is a procedure;the official result(represented in the routine's body by the entity Resulr)if it is a function.To achieve the effect of multiple results,you can either: Use a function that returns an object with several fields (or more commonly a reference to such an object). Use a procedure that sets several fields of an object,corresponding to attributes that the client may then query. The first technique is appropriate when the result is truly made of several See chapter 23,espe- components;a function may not for example return two values corresponding to the title cially"The aposteri- and publication year of a book,but it may return a single value of type BOOK,with"page 800. attributes title and publication year.The second technique is applicable for a routine that, besides its principal job,sets some status indicators.We will study it,as well as the more general question of side effects,in the discussion of module design principles
446 MORE O-O MECHANISMS §13.2 So although a call q (a) can never change the value of a — the corresponding object if a is expanded, the reference otherwise — it can, in the reference case, change the attached object. There are many reasons for not permitting routines to modify their arguments directly. One of the most striking is the Conflicting Assignments To Actual trick. Assume a language that permits assignments to arguments, and a procedure dont_I_look_innocuous (a, b: INTEGER) is -- But do not trust me too much. do a := 0; b := 1 end Then consider the call dont_I_look_innocuous (x, x) for some entity x. What is the value of x on return: 0 or 1? The answer depends on how the compiler implements formalto-actual update on routine exit. This has fooled more than a few Fortran programmers, among others. Permitting argument-modifying routines would also force us to impose restrictions on actual arguments: the actual corresponding to a modifiable formal must be an element that can change its value (a writable entity); this allows variable attributes, but not constant attributes, Current, or general expressions such as a + b. By precluding argumentmodifying routines we can avoid imposing such restrictions and accept any expression as actual argument. As a consequence of these rules, there are only three ways to modify the value of a reference x: through a creation instruction !! x…; through an assignment x := y; and through a variant of assignment, assignment attempt x ?= y, studied in a later chapter. Passing x as actual argument to a routine will never modify x. This also means that a routine returns at most one result: none if it is a procedure; the official result (represented in the routine’s body by the entity Result) if it is a function. To achieve the effect of multiple results, you can either: • Use a function that returns an object with several fields (or more commonly a reference to such an object). • Use a procedure that sets several fields of an object, corresponding to attributes that the client may then query. The first technique is appropriate when the result is truly made of several components; a function may not for example return two values corresponding to the title and publication year of a book, but it may return a single value of type BOOK, with attributes title and publication_ year. The second technique is applicable for a routine that, besides its principal job, sets some status indicators. We will study it, as well as the more general question of side effects, in the discussion of module design principles. WARNING: invalid routine text. For purposes of illustration only. On constant attributes see chapter 18. See chapter 23, especially “The a posteriori scheme”, page 800