(ref.doc)meyer 191193

Function `clone' is frozen because it relies on `copy'. The latter, of
course, is not frozen. Just redefine `copy', and `clone' will follow
automatically.

The idea behind this convention is, as usual, a combination of safety
and convenience requirements (see the note at the end of this
message):

	- Convenience: when you redefine either one of `clone' and `copy',
	the other should follow. It would be a nuisance to have to
	redefine both. So it suffices to redefine the one (`copy')
	in terms of which the semantics of the other (`clone') may
	be expressed. (A `clone' may be viewed as a creation followed
	by a `copy'.)

	- Safety: redefining one of these features without redefining the
	others would almost certainly be a mistake; the semantics of the
	two operations should be compatible. So by making `clone' frozen
	to ensure that it always follows the semantics of `copy' we
	avoid mistakes.

Note that if you are doing things properly you still have to redefine
`is_equal' when you redefine `copy', to guarantee that the semantics of
equality remains compatible with the semantics of copying. Here there
is no automatic way of ensuring consistency, so you must take care
`is_equal' yourself. But only two redefinitions are necessary (`copy'
and `is_equal'); the features whose semantics may be defined in
terms of these two (`clone' and `equal') follow automatically. 

An example of redefinition of `copy' and `is_equal' occurs in class
STRING from the Kernel library. What we want these features to copy
and compare is strings, not string descriptors. The redefined
versions achieve this goal. You will not find any redefinition
of `clone' in class STRING, because none is needed (or possible
since `clone' is frozen); but a `clone' on strings will follow
the redefined semantics of `copy' and hence do exactly
what you want - duplicate a string, not just the descriptor.

...

One more general comment about an observation made at the beginning of
this note. I believe that one of the major goals of software, library
and language design is to find mechanisms that improve *both*
convenience and safety. It is relatively easy to meet just one of
these goals; for example you can add many ``bells and whistles'' which
make the users' life more convenient at first but do not enhance safety
and can in fact reduce it; or you can add harsh rules and constraints
which help safety, chastity-belt style, but hamper user's convenience.
Real winners are those facilities that foster both goals. Two examples
from the design of languages (rather than libraries or software systems),
one important, the other more modest:

	- Static typing (if designed properly) obviously helps safety,
	but also convenience since it encourages software writers
	to state explicitly what each entity will be used for
	and hence greatly facilitates later work on the software.
	(When you read `x: EMPLOYEE' you know what the values of
	`x' should look like; in an untyped language `x' could be
	the number 2 one minute and an aircraft carrier the next.)

	- A little lexical property of Eiffel also proceeds from the
	same reasoning: in integers you may use an underscore as in
	Ada, but there is a rule, not present in Ada, that if you
	do use underscores you must do so systematically, digits
	being grouped by three except for the leftmost group if too
	small. The underscores are good for convenience (read
	here clarity), since 78_756_444 clearly shows the units,
	thousands and millions and hence is more readily understandable
	than 78756444; but the grouping-by-three rule makes underscores
	good for safety too, since there is a much better chance that a
	mistakenly added or forgotten digit will yield to a lexical error
	that the compiler will spot.

Much of this applies, beyond languages and libraries, to the general
problem of designing software systems that offer to their users both
convenience and safety.