$18.3 CONSTANTS OF CLASS TYPES 647 make cartesian (a,b:REAL)is --Initialize with real part a,imaginary part b. do x:=a;y:=b end ..Other routines (x and y are the only attributes)... end You may want to define the complex number i,with real part 0 and imaginary part 1.The first idea that comes to mind is a manifest constant notation such as i:COMPLEX is "Expression specifying the complex number (0,1)" How can you write the expression after is?For simple types,the manifest constants were self-evident:345 is a constant of type integer,'4'of type character.But no such predefined notation is available for developer-defined class types. One could imagine a notation based on the attributes of the class;something like Not a retained nota- i:COMPLEX is COMPLEX (0.1 tion.For purposes of illustration only. But such an approach (although present in some O-O languages)is incompatible with the principles of modularity which serve as the basis for object technology.It would mean requiring clients of COMPLEX to describe constants in terms of the implementation. This breaks information hiding.You could not add an attribute,even a secret one,without invalidating client code;neither could you re-implement an attribute such as x as a function(to switch internally to a polar representation). Besides,how could you make sure that such manifest constants will satisfy the class invariant if there is one? This last remark opens the way to a correct solution.An earlier chapter noted that it is the responsibility of the creation procedures to make sure that every object satisfies the invariant immediately upon creation.Creating objects in any other way (apart from the safe companion mechanism,clone)would lead to error situations.So we should look for a mechanism that,rather than manifest objects in the above style,will rely on the usual technique for object creation. Once functions We may view a constant object as a function.For example i could be defined within class COMPLEX itself as i:COMPLEX is --Complex number with real part 0 and imaginary part I do !Result.make cartesian (0,1) end§18.3 CONSTANTS OF CLASS TYPES 647 make_cartesian (a, b: REAL) is -- Initialize with real part a, imaginary part b. do x := a; y := b end … Other routines (x and y are the only attributes) … end You may want to define the complex number i, with real part 0 and imaginary part 1. The first idea that comes to mind is a manifest constant notation such as i: COMPLEX is “Expression specifying the complex number (0, 1)” How can you write the expression after is? For simple types, the manifest constants were self-evident: 345 is a constant of type integer, 'A' of type character. But no such predefined notation is available for developer-defined class types. One could imagine a notation based on the attributes of the class; something like i: COMPLEX is COMPLEX (0, 1) But such an approach (although present in some O-O languages) is incompatible with the principles of modularity which serve as the basis for object technology. It would mean requiring clients of COMPLEX to describe constants in terms of the implementation. This breaks information hiding. You could not add an attribute, even a secret one, without invalidating client code; neither could you re-implement an attribute such as x as a function (to switch internally to a polar representation). Besides, how could you make sure that such manifest constants will satisfy the class invariant if there is one? This last remark opens the way to a correct solution. An earlier chapter noted that it is the responsibility of the creation procedures to make sure that every object satisfies the invariant immediately upon creation. Creating objects in any other way (apart from the safe companion mechanism, clone) would lead to error situations. So we should look for a mechanism that, rather than manifest objects in the above style, will rely on the usual technique for object creation. Once functions We may view a constant object as a function. For example i could be defined within class COMPLEX itself as i: COMPLEX is -- Complex number with real part 0 and imaginary part 1 do !! Result ● make_cartesian (0, 1) end Not a retained nota￾tion. For purposes of illustration only