$19.3 ON USING METAPHORS 671 r.Such a rule,ifjustified,should be made part ofthe language.But as the authors themselves imply in the quoted excerpt this would be too harsh.The rule would make it impossible,for example,to write a call my stack.item.some routine which applies some routine to the topmost element ofmy stack;yet any altemative phrasing is heavier and less clear. For the first few weeks after the initial design of the notation of this book,years ago, multi-dot calls of the form a.bc were not supported.This limitation proved insufferable and we did not rest until it was removed. “SELECTIVE EX. Examination of the rationale for the Law,and for its exceptions,suggests that the PORTSANDINFOR-authors may not have considered the notion of selective export,through which one can LATION HIDING” 7.8page191. export a feature of a class Cto specific clients having a close relation to C,while keeping it away from all other clients.With this mechanism,there may be no need for a Demeter- like law. These observations yield our last precept: Fixing What Is Broken methodology principle If you encounter the need for many advisory negatives: Examine the supporting tool or language to determine if this reflects deficiencies in the underlying design. If so,consider the possibility of shifting over some of the effort from documenting that design to correcting it. Also consider the possibility of eliminating the problem altogether by switching to a better tool. 19.3 ON USING METAPHORS ANDROMAQUE: I do not understand abstractions. CASSANDRA: As you like.Let us resort to metaphors. Jean Giraudoux,The Trojan War Will Not Happen,Act I. In this meta-methodological discussion it is useful to reflect briefly on the scope and limits of a powerful expository tool:metaphors. Everyone uses metaphors-analogies-to discuss and teach technical topics.This book is no exception,with such central metaphors as inheritance and Design by Contract. The name of our entire subject,indeed,is a metaphor:when we use the word"object"to talk about some computing concept,we rely on a term loaded with everyday connections, which we hijack for a very specific purpose. In scientific discourse metaphors are powerful,but they are dangerous.This is particularly applicable to software,and even more to software methodology.§19.3 ON USING METAPHORS 671 r. Such a rule, if justified, should be made part of the language. But as the authors themselves imply in the quoted excerpt this would be too harsh. The rule would make it impossible, for example, to write a call my_stack ● item ● some_routine which applies some_routine to the topmost element of my_stack; yet any alternative phrasing is heavier and less clear. For the first few weeks after the initial design of the notation of this book, years ago, multi-dot calls of the form a ● b ● c were not supported. This limitation proved insufferable and we did not rest until it was removed. Examination of the rationale for the Law, and for its exceptions, suggests that the authors may not have considered the notion of selective export, through which one can export a feature of a class C to specific clients having a close relation to C, while keeping it away from all other clients. With this mechanism, there may be no need for a Demeter￾like law. These observations yield our last precept: 19.3 ON USING METAPHORS ANDROMAQUE: I do not understand abstractions. CASSANDRA: As you like. Let us resort to metaphors. Jean Giraudoux, The Trojan War Will Not Happen, Act I. In this meta-methodological discussion it is useful to reflect briefly on the scope and limits of a powerful expository tool: metaphors. Everyone uses metaphors — analogies — to discuss and teach technical topics. This book is no exception, with such central metaphors as inheritance and Design by Contract. The name of our entire subject, indeed, is a metaphor: when we use the word “object” to talk about some computing concept, we rely on a term loaded with everyday connections, which we hijack for a very specific purpose. In scientific discourse metaphors are powerful, but they are dangerous. This is particularly applicable to software, and even more to software methodology. Fixing What Is Broken methodology principle If you encounter the need for many advisory negatives: • Examine the supporting tool or language to determine if this reflects deficiencies in the underlying design. • If so, consider the possibility of shifting over some of the effort from documenting that design to correcting it. • Also consider the possibility of eliminating the problem altogether by switching to a better tool. “SELECTIVE EX￾PORTS AND INFOR￾MATION HIDING”, 7.8, page 191