Touch of class typos
Typos for "Touch of Class" draft
How to report a typo
Report it under the appropriate chapter title below. Please include the original section number. The page number is less important as it changes. The best is to copy-paste the relevant text extract and mark the faulty word(s), for example by **...**. It is convenient to show the extract as a display (start lines with spaces) and also, if you wish, to give your name.
For example:
In section 16.1, just after the first figure: Money, Pass, Map, Louvre, Orsay Money, Pass, **Louvre, Map**, Orsay Money, Map, Pass, Louvre, Orsay The second one is wrong. -- Luchin Doblies, 1.12.2008.
(Indeed Luchin Doblies reported this error -- thanks! BM.) The entry should appear in the section for the corresponding chapter (it does now). I am sorry that I will not be able to respond to individual comments, but I will consider all reports and correct the text as needed.
As errors get corrected I strike them out.
Preface etc.
from Draft 22.02, 23 August 08 19:15 (Santa Barbara) page v, section Preface. in the 'note' clause of the class PREFACING. replace: "] by: ]" -- Eric Bezault, 12 December 2008
from Draft 22.02, 23 August 08 19:15 (Santa Barbara)
page xiii, section student_preface/Abstraction. middle of second paragraph. replace: you'll been encouraged by: you'll be encouraged -- Eric Bezault, 12 December 2008
from Draft 22.02, 23 August 08 19:15 (Santa Barbara)
page xv, section instructor_preface. second paragraph, third bullet. text: Eiffel and Design by Contract action: put the last letter of "Contract" in bold. -- Eric Bezault, 12 December 2008
from Draft 22.02, 23 August 08 19:15 (Santa Barbara) page xxi, section student_preface/OUTSIDE-IN: THE INVERTED CURRICULUM/The supporting software. middle of second paragraph. replace: In the seond week by: In the second week -- Eric Bezault, 12 December 2008
from Draft 22.02, 23 August 08 19:15 (Santa Barbara) page xxv, section student_preface/TECHNOLOGY CHOICES/Eiffel and Design by Contract. right margin. replace: at tinyurl.com/cq8gw.. by: at tinyurl.com/cq8gw. action: remove extra dot. -- Eric Bezault, 12 December 2008
from Draft 22.02, 23 August 08 19:15 (Santa Barbara)
page xxix, section student_preface/TECHNOLOGY CHOICES/Why not Java?. replace: university context,it is meant by: university context, it is meant action: space after comma. -- Eric Bezault, 12 December 2008
from Draft 22.02, 23 August 08 19:15 (Santa Barbara)
page xxxiv, section student_preface/TOPICS COVERED. paragraph starting with "Part III" text: It makes no attempt at action: missing end of sentence. -- Eric Bezault, 12 December 2008
1 The industry of pure ideas
page 5, section 1.1: Computers and related devices are called hardware, indicating that — although they are getting ever lighter — computers are the kind of machine that will hurt your feet. Programs **and all that relates to them** are by contrast called software, a word made up in the 1950s when programs emerged as topic of interest. Comment: one may argue that hardware may relate to hardware (depending on the definition of the relation). As the point is to separate the two concepts, to avoid confusion I would drop **and all that relates to them**. -- MP, 8/2/2009
page 11, picture caption: **(d) GPS navigation system**. For consistency with the iPhone, you may consider adding that it is a Garmin gps. -- MP, 8/2/2009
page 13, towards the end: This book emphasizes throughout, along with practices that **make your programs good for the computer** — for example, designing programs so that they will run fast enough —, practices that make them good for human readers. Remark: The way in which the sentence is formulated is not smooth and crystal clear to me. A suggestion could be: This book emphasizes throughout, along with programming practices that put to good use a computer processing power, practices that make programs understandable by human readers. -- MP 8/2/2009
page 14, at the end of box Touch of folk history: This did not deter **the programmer**: “See the holes? They are the software.” Could be: This did not deter one of the programmers: “See the holes? They are the software.” -- MP 8/2/2009
page 16, exercise 1-E.3, third bullet point: The exact set of letters does not**,** matter but Comment: Move the comma after the word matter. -- MP 8/2/2009
2 Dealing with objects
page 18, second line: The book**,** applies systematic typesetting conventions Comment: comma should be dropped -- MP, 15/2/08
page 18, in box Touch of style: (sometimes bold or italics according to precise rules**) Comment: I would add: (sometimes bold or italics according to precise rules that will be specified) -- MP, 15/2/08
page 18, line after box on class Preview: The first line says you are looking at a **small** “class” Comment: as the first line does not say that the class is "small", I would drop the word "small": The first line says you are looking at a “class” -- MP, 15/2/08
page 19, box title "**Magic?". Did you considered the title "Touch of magic?"? -- MP, 15/2/08
page 25, after the first code box: Paris.display Comment: you use the term "object", and then again many times in the same page. As you will define it on page 27, I would put a reference here, or give an informal definition, especially because you use it in the Touch of Semantics box (page 25) to define a feature call. -- MP, 15/2/08
page 27, sub-section "Objects you can and cannot kick", first bullet point, two lines before the end: ...your foot. **(Buying this book does not entitle you to a refund of medical expenses.)**. Comment: punctuation before and after the parentheses (or parentheses themselves) is (are) misplaced. Suggestion: ...your foot. Please be aware of the fact that buying this book does not entitle you to a refund of medical expenses.. -- MP, 15/2/08
pages 27 and 28: Comment: there are many references to "**Notre-Dame**" (I counted 5), but the figure on page 27 shows "Saint-Michel" as metro station. I would keep Saint-Michel everywhere to avoid confusion (not everybody may know that the real stop is "Saint-Michel Notre-Dame") -- MP, 15/2/08
page 28: last bullet list: first bullet "**or any other specified by its index**" Comment: you did not defined an index of a leg. Here you could drop the sentence fragment above without conceptually losing anything: Remove the first leg of the route, or the last leg, or any other. -- MP, 15/2/08
page 28: last bullet list: second bullet: **for example a metro leg from Notre-Dame to Jussieu (4 stations, see map on the previous page); the route will be changed to involve 3 legs, 3 metro lines, and 8 stations; the result now starts at Louvre and ends at Jussieu.** Comment: where is Jussieu? The "map on the previous page" does not help, nor the one on page 24. -- MP, 15/2/08
page 28: last bullet list: third bullet: For example we can make Route1 start with a leg going from Opéra to Louvre; Comment: It would be nice to locate on a map Opéra. -- MP, 15/2/08
page 29: line 3: **With a remove query**, it would be one less. Comment: It should be something like: "If you remove a leg, the same query above would report one less." -- MP, 15/2/08
page 31: box "Definitions: Feature, Query, Command", second bullet: A feature that may **modify** an object is called a command Comment: you don't define "modify". At the bottom of page 28 there was a definition of "change" of an object. I would use the same word in both cases, or put a reference here to the previous definition, or repeat the definition. -- MP, 15/2/08
page 31, 4 lines before the end: are **defined** for you Comment: as how to "define" an object has not been defined, I would use are created for you instead. -- MP, 15/2/08
page 33, first line: "**Palsis**" should be "Palais" -- MP, 15/2/08
page 34, Exercise 2-E.2, 3 lines before the end. There is a parenthesis to drop. -- MP, 15/2/08
page 35, 3rd bullet; **If either of the previous two relations holds between two terms “relies on” also holds** Comment: a comma is missing: If either of the previous two relations holds between two terms, “relies on” also holds -- MP, 15/2/08
page 35, exercise 2-E.3, point 2. **my_paragraph_remove_last**. Comment: my_paragraph_remove_last_word is a better name -- MP, 15/2/08
page 36, exercise 2-E.3, point 5. **my_paragraph.character_count (i)** seems a bit confusing example to me. Comment: looking at the semantics, I would suggest my_paragraph.word (i), to get the i-th word in a paragraph; then we can apply to the resulting word feature character_count, a query that should be a feature of class WORD. -- MP, 15/2/08
page 36, exercise 2-E.4 **Assume that you are building an MP3 player entirely software.** I am confused by the phrasing. Comment: "Assume you are building a software model of a MP3 player." looks better to me. -- MP, 15/2/08
from Draft 22.02, 23 August 08 19:15 (Santa Barbara) page 17. second paragraph. text: Everything else you will learn here and on the supporting Web site action: missing end of sentence. -- Eric Bezault, 12 December 2008
from Draft 22.02, 23 August 08 19:15 (Santa Barbara)
page 21, section 2.2 OBJECTS AND CALLS/Editing the text. second paragraph. replace: important element ofprogram texts by: important element of program texts action: add space. -- Eric Bezault, 12 December 2008
from Draft 22.02, 23 August 08 19:15 (Santa Barbara) page 25, section 2.2 OBJECTS AND CALLS/Dissecting the program. second paragraph. replace: Previous rules rules addressed by: Previous rules addressed -- Eric Bezault, 12 December 2008
from Draft 22.02, 23 August 08 19:15 (Santa Barbara)
page 25, section 2.2 OBJECTS AND CALLS/Dissecting the program. second paragraph. text: Then to highlight Line 8 we execute action: the code "Line8.highlight" appears on the next page after the end of the paragraph instead of embedded within the paragraph. -- Eric Bezault, 12 December 2008 I don't see the problem now so I assume it was fixed earlier
from Draft 22.02, 23 August 08 19:15 (Santa Barbara)
page 31, section 2.3 WHAT IS AN OBJECTS/Objects: a definition. second paragraph. replace: It is also s good by: It is also good -- Eric Bezault, 12 December 2008 I don't see this, so I assume the sentence was removed.
3 Program structure basics
from Draft 22.02, 23 August 08 19:15 (Santa Barbara) page 43, section 3.5 NESTING AND THE SYNTAX STRUCTURE. in the gragh. replace: -- Show city info including a monument.. by: -- Show city info including a monument. action: remove one dot. -- Eric Bezault, 12 December 2008
from Draft 22.02, 23 August 08 19:15 (Santa Barbara) page 48, section 3-E.1 Vocabulary. in right margin. text: The definition of "class" may be less precise than the others. action: remove this text. It's copy/pasted from 2-E.1 -- Eric Bezault, 12 December 2008
4 The interface of a class
from Draft 22.02, 23 August 08 19:15 (Santa Barbara) page 52, section 4.2 CLASSES. in sixth paragraph, second bullet. text: there some names such as Paris and Route1 action: The 's' in 'such' should not be in italic. -- Eric Bezault, 12 December 2008
5 Just Enough Logic
6 Creating objects and executing systems
7 Control structures
Corrections by Raphaël Meyer
Page 142: the four bulletpoints are not parallel. bulletpoint 3 refers to its while the first two start with "the". the fourth one is completely different than the first 3.
Page 143: addition box towards the top. there is an error in the calculation. the sum of the two numbers should be 729 (not 29)
Page 144: paragraph underneath heading "Precision and explicitness: algorithms vs recipes": The word "follow" on the third line should be "following".
Page 145: First paragraph that starts with "In German and French": At the end of the first sentence, I would say "heat the thing up at some point" rather than "heat up the thing at some point".
The final sentence of the first paragraph is not grammatically correct: "Only the Italian version mentions this detail — 'cook according to the times given' — without which the pictures would be meaningless." I would say "Only the Italian version mentions this detail - cook according to the times given - which gives meaning to the pictures."
Page 145: The paragraph that starts with "For algorithms, as opposed to informal recipes": The second clause should read "as opposed to for informal recipes"
Page 147: In the first bulletpoint: The final sentence is a little long and confusing. I would change the second half of it to the following: "... software elements, this book tends to use the word system rather than the word 'program' (which may still suggest the idea of doing just one task)'"
Page 147: The second bulletpoint: The first sentence is confusing. I would say "The description of the data structure—in the object-oriented approach of this book, the object structure — to which processing steps apply is as important to a program as the steps themselves."
Page 148: Under the "sequence" bulletpoint, final sentence: "would executed" should be "would execute" or "would be executed"
Page 150: final paragraph, bottom of the page, first sentence: "not any more get" should be "no longer receive" or "no longer be given"
Page 151: Textbox with "Touch of Style" as its header: the bulletpoints are formatted strangely. Shouldn't the first line be aligned with the second line for each bullet?
Page 152: Paragraph beginning with "Even on separate lines ...": "put two version of the same ..." should be "put two versions of the same ..."
Page 153, first paragraph starting with "Note that the syntax ...": The sentence "but it is useful to allow it for when a sequence appears as part of a larger structure." is unclear. REvise the first part to clarify between "it" and "it".
Page 154, textbox entitled "Correctness": the word "compound" in the second bulletpoint should be capitalized.
Page 154, bottom of the page, final 3 lines: the formatting seems incorrect. The final sentence should all be on one line.
Page 155, paragraph starting with "A typical example of loop": the sentence should read "A typical example of a loop ..."
Page 155, middle of the page: There appears to be a diagram or picture missing next to the tagline "Highlighting a station"
Page 157, first paragraph that starts with "This ensures that ...": the clause "the third step to I2 for i = 3" should read "the third step to I3 for i = 3 ..."
PAge 158, last sentence of the paragraph starting with "the 'maximum' example ...": The last sentence reads "and the invariant INV (s), where s is a subset N1, N2, ..., Ni of DS, is that we have found the maximum of s." This should be reworded since it is not clear grammar.
Page 158: first bulletpoint under "Note - in the general case ...": Typo: "sufficently" should be "sufficiently"
Page 163: second bulletpoint underneath the paragraph starting with "The loop postcondition principle ... ": The fist part of the sentence reads "Sufficiently flexible to let us extend it from ..." I think it would be clearer if it read "Sufficiently flexible that we can extend it from ..."
Page 164, textbox entitled "Loop Variant": Typo: "Afterexecution" should be "After execution"
PAge 165, final paragraph that starts with "You may well feel ...": The third sentence reads "If you have ever try ..." but should read "If you have ever tried ...". Further, the sentence then reads "it might very well be the result of such ..." but should read "it might very well have been the result of such ..."
Page 168, final paragraph starting with "... for successive values of i ...": The second sentence reads " ... used for iterating over object structures such as list." Is this correct grammar? Should it not be " ... used for iterating over object structures such as lists."?
8 Routines, functional abstraction and information hiding
9 Variables, assignment and references
PART II: HOW THINGS WORK
10 Just enough hardware
11 Describing syntax
12 Programming languages
13 Compilers and friends: the basic software tools
PART III: ALGORITHMS AND DATA STRUCTURES
14 Fundamental data structures, genericity, and algorithm complexity
p. 353, "naming conventions for features of reusable components" does not really belong under the bullet "Algorithm complexity"
p. 357, "safety and flexibility," --> "safety and flexibility."
p. 359, "non -generic" --> "non-generic".
p. 360, "and hash tables —, all" --> "and hash tables — all"
p. 361 top, "find if a part" --> "determine if a part" or "find out if a part"
p. 361 middle, "G will denotes" --> "G will denote" or "G denotes"
p. 369, "complexity. assessing" --> "complexity. Assessing"
Continue on p. 370.
15 Recursion and trees
16 Devising and engineering an algorithm: Topological Sort
In section 16.1, just after the first figure: Money, Pass, Map, Louvre, Orsay Money, Pass, **Louvre, Map**, Orsay Money, Map, Pass, Louvre, Orsay The second one is wrong. -- Luchin Doblies, 1.12.2008.
Section 16.3, topic "Cycles in the constraints", line 4-5: "A topological sort program gets its input **in the form individual ordering constraints**, ..." Missing "of": "in the form of" -- L.D., 1.12.2008
Section 16.4, topic "The Loop", second last line of the code-square: if “Any elements remain” then-- Report cycle: cycle_found := True “Insert these elements into **cyclist**” end I believe cyclist should be plural, "cyclists". -- L.D., 1.12.2008
Section 16.4, topic "The Candidates", second page, line 4: "What concrete **date** structure should we use for candidates?" "date structure" instead of "data structure". -- L.D., 1.12.2008
Section 16.7, second line: "..., such as the "<“ relation on numbers." The quotes do not match in font. -- L.D., 1.12.2008
PART IV: OBJECT-ORIENTED TECHNIQUES
17 Inheritance
18 Operations as objects: agents and lambda calculus
(Comments by Annie Meyer)
Page 653
It has been particularly successful for Graphical User Interfaces (GUI), which we’ll use as our primary example.
Tu avais dit que tu voulais retirer toutes les contractions.
Page 654
Welcome to the modern world. If you write a program with a GUI, you let users choose, at each step, what they want to do, out of many possibilities — including some unrelated your program, since a user may go to another window, for example to answer an email.
Unrelated to your program ? le to manque
Page 655
Figure à ajouter
but this suffers from all the problems we have seen with multiple-choice algorithm structures (as part of the justification for dynamic binding): it’s big and complex, and highly sensitive to any change in the setup.We want a simpler and more stable architecture, which we won’t have to update each time there is a new control.
Ajouter un espace apres setup. et We
Page 656
Such a system might have sensors monitoring temperature, pressure, humidity; any new recording, or just those exceeding some preset values, may trigger an event which some elements of the software are prepared to handle.
Deux fois some
Tu peux remplacer le deuxième par other
Page 657
Usually there’s more: when and where did Columbus sail? What were the cursor coordinates? But in some cases all that matters is that the event occurred, as with a timeout event indicating that a previously set deadline has passed.
it’s an operation that makes information (the arguments a, b, c) available to a software element (the feature f ).
Page 658
The term “argument” highlights the similarity with routines. Pushing this similarity further, we’ll assume that the arguments are grouped in an ordered list, like the arguments in a call x.f (a, b, c).
The notification model is more flexible and we’ll assume it from now on.
before it’s triggered the event does not exist, and afterwards it’s too late to subscribe to it!
after you’ve spotted the headline on
Page 659
Although we might define an event type for each key on the keyboard, it’s more attractive to use a single “key press” event type of signature [CHARACTER], where the argument is the key code.
As always when you are hesitating about introducing a class, the criterion is “is this a meaningful data abstraction, with a set of well-understood operations applicable to all instances?”. Here:
Il y a un point en trop avant Here:
If we decided to build a class to represent a particular event type, its instances would be events of that type; but they have no useful features. True, each event has its own data (the arguments), but there’s no meaningful operation on the event other than accessing such data.
Page 660
E3 At any time, a publisher can trigger an event. This will cause execution of actions registered by subscribers for the event’s type. These actions will can use the event’s arguments
c'est will ou can? La phrase est terminée ou pas?
Page 661
E2 A subscriber is any element that needs to handle such GUI events; it registers the routines it wants to execute in response For example you may register, for the mouse click event type on a button that says “OK” in a file saving dialog, a routine that saves the file.
Il manqué un point avant For example
the other way around it’s more a matter of methodology, and we will see how various architectural solutions fare against this criterion.
Page 662
It is not possible (points 1, 5) to subscribe to an event; as we have seen, the event does not exist until it has been raised, and when it has been raised that’s too late. (Nice idea, though: wouldn’t you like to subscribe retroactively to the event “IBM’s shares rise by at least 5%”?) A subscriber subscribes to an event type — to declare that it wishes to be notified of any event of that type raised during execution.
“A subscriber can handle multiple events from multiple publishers” (point 2): this might seem to suggest some sophisticated concurrent computation scheme, where a subscriber catches events from various places at once, but
in reality is just a mundane observation: a given subscriber may register for
several event types, and several publishers may trigger events of a given type.
In reality it is just ......, le it manque non?
Point 5 states that when “an event” has multiple subscribers, each will handle it synchronously (meaning right away, blocking further processing) when “an event” is raised. Read literally, this would suggest that two
“events” are involved! That’s not the idea: the sentence is simply trying to
say that when multiple subscribers have registered for a certain event type, they handle the corresponding events synchronously. It uses a single word, in the same breath, with two different meanings.
Je continue à te signaler les contractions si tu veux les retirer.
Page 663
Definition: Context In event-driven design, a context is a boolean expression specified by a subscriber at registration time, but evaluated at triggering time, such that the
registered action will only be executed if it the evaluation yields True.
Un mot en trop "it"?
Page 665
you’ll have to add some program text, often called “glue code”; the less of it the better. The last requirement is critical to the quality of a system’s architecture, especially when the goal is to build user interfaces: you shouldn’t have to design the core of an application differently because of a particular interface.
Page 671
it’s easy to ease the restrictions later if you find that new classes need the features.
Page 672
We’ll call such descendants “subscriber classes” and their instances “subscribers”.
Page 673
With handle as written above you woll only find them at run time, through the tests
Will?
on the size and element types of args; that’s too late to do anything serious about the issue, as reflected by the rather lame “Do nothing, or report error” above: doing nothing means ignoring an event (is that what we want, even if the event is somehow deficient since it doesn’t provide the right arguments?); and if we report an error, report it to whom? The message should be for the developers — us! — but it’s the poor end user who will get it.
Pourquoi "poor" end user? Je trouve ce mot inutile.
Page 674
The only missing part of the Observer pattern’s implementation is the body of the publish procedure in PUBLISHER, although I hope you have already
composed it in your mind. It’s where the pattern gets really elegant:
Subscribers directly subscribe to publishers. This causes undesirable coupling between the two sides: subscribers shouldn’t have to know which
Page 676
it’s also much simpler. The key boost comes from the agent and tuple mechanisms.
We won’t have PUBLISHER or
SUBSCRIBER classes any more, but just one class — yes, a single class solves the entire problem — called EVENT_TYPE.
Page 677
Of course we’ll explore the implementation too, as I am sure you’ll want to see it. (It will actually be more fun if you try to devise it yourself first.)
One of the advantages is that you don’t need to worry about when to create the object; whichever part of the execution first uses left_click will (unknowingly) do it. We’ll see in just a moment where this declaration of the event type should appear; until then let’s assume that subscriber and publisher classes both have access to it.
Page 678
Whenever the context is relevant — subscribers don’t just subscribe to an event type as in [41], but to events occurring in a context, as in [42]—the proper architectural decision is to declare the relevant event types in the corresponding context classes.
For events that are relevant independently of any context information, declare the event type in a generally accessible class.)
Parenthèse ou pas? Ou une en trop ou une manquante.
Page 680
In an environment with manual memory reclamation (C, C++), it’s even worse. In either case we have a source of “memory leak”: as execution fails to return unneeded space, memory occupation continues to grow.
Page 682
MVC revisited One of the consequences of the last design is to simplify the overall architecture suggested by the Model-View-Controller paradigm. The Controller part is “glue code” and it’s good to keep it to the strict minimum.
Page 683
This solution achieves complete uncoupling between model and view; in a typical application the controller will still be still a small component, achieving
still 2 fois
(So from the order of events it’s really the “Subscribe-Publish” paradigm.)
Page 685
you shouldn’t use client elsewhere if the conditions are the same. Consistency is also particularly important for an API, to ensure that once programmers have learned to use a certain group of classes they can expect to find similar conventions in others. Such tasks can be carried out to improve existing designs, an activity known as refactoring. It’s indeed a good idea always to look at existing software critically, but prevention beats cure.
Touch of Methodology:
Assessing software architectures
When examining possible design solutions for a given problem, discuss alternatives critically. The key criteria, are: reliability, extendibility, reusability, and simplicity.
Pourquoi une , avant are?
18.8 FURTHER READING
Il n'y a pas de consistence dans les espaces entre les articles ou livres cites et les commentaires que tu ajoutes.
Le plus simple serait de rajouter des espaces plutôt de d'en retirer car sinon cela va modifier la pagination puisque la page 688 est blanche.
19 Event-driven design
20 Program correctness and proofs
PART V: TOWARDS SOFTWARE ENGINEERING
21 Introduction to software engineering
PART VI: APPENDICES
A Using the EiffelStudio environment
B Eiffel syntax specification
C An introduction to C++ (material by Nadia Polikarpova)
p. 770, Section "Derived types": "since it is possible to assigned a dereferenced" --> "since it is possible to assign a dereferenced" -- Stephan 18/2/2009
p. 777, "a::x" --> "A::x" -- Stephan 18/2/2009
p. 780, "trying to access a non-existen object" --> "trying to access a non-existing object" -- Stephan 18/2/2009
p. 782, in "exception through throw ()).", the full-stop should be black (not blue) -- Stephan 18/2/2009
p. 783 top, "If no matching try block" --> "If no matching catch block" -- Stephan 18/2/2009
p. 789 bottom, "assert b" --> "assert b;" -- Stephan 18/2/2009
p. 793 top, "Blocks correspond to Eiffel compound and consists of" --> "Blocks correspond to Eiffel compounds and consist of" or "Blocks correspond to Eiffel compound statements and consist of" -- Stephan 18/2/2009
p. 794, top box: "for (init_statement expression;" --> "for (init_statement; expression;" -- Stephan 18/2/2009
p. 798 top, in "a fraction part, an e symbol, followed by an optionally signed": the e symbol is also optional. -- Stephan 18/2/2009
D An introduction to Java (material by Marco Piccioni)
E An introduction to C# (material by Benjamin Morandi)
p. 742, 4th line from the bottom: "reclaims an object;." --> "reclaims an object." -- Stephan 16/2/2009
p. 743, 2nd line from the top: "No overloading here;" --> "There is no overloading here" or "Destructors may not be overloaded" -- Stephan 16/2/2009
p. 743, Last line of text: "use at your own risk" --> "use them at your own risk" -- Stephan 16/2/2009
p. 744, Get consistency among "One-dimensional array" and "Two dimensional arrays", i.e. use "Two-dimensional array" -- Stephan 16/2/2009
p. 746, There is a black line in the margin next to the top box. -- Stephan 16/2/2009
p. 746, "C [G, H –> T create make end" --> "C [G, H –> T create make end]" -- Stephan 16/2/2009
p. 748, in "do {statements} while (condition)", the first curly brace should be blue. -- Stephan 16/2/2009
p. 748, "Typical causes of exception" --> "Typical causes of exceptions" -- Stephan 16/2/2009
page 756: Title of "INHERITANCE" section should be de-capitalized like in "Inheritance" for consistency with other section titles. -- MP 14/2/2009
p. 757, Just before B.5: "if (exp is T)" --> "if (exp is U)" -- Stephan 16/2/2009
p. 760, "The rest as before ...]" --> "The rest as before ...}" -- Stephan 16/2/2009
p. 761, "returns into an array" --> "returns in an array" or "returns an array of attributes" -- Stephan 16/2/2009
New appendix D - From C++ to C
p. 801 bottom, "compilers, including for Eiffel" --> "compilers, including Eiffel compilers" or "compilers, including ones for Eiffel" -- Stephan 18/2/2008
Typos reported by Ernst Leisi (no chapter numbers given)
(Second version [the one with 910 pages])
s. 51 - What this tells us is that the objects our programs manipulate classify ... sounds kind of strange... the objects our programs
themselves naturally into certain classes
s. 59 - Line8.i_th (2) is “La_Motte” and so on. ... there is no La_Motte on the picture
s. 61 - Line8.remove_all_remove_all_segments ... why two times remove_all ?
s. 69 - invariant (where * denotes multiplication: ... missing " ) "
s. 84 - (a = b) or (c and ((not d) = e))) ... the last " ) " is one too much or there should be one at the beginning ( " ( " )
s. 97 - Line8.i_th (2)).is_exchange ... " ) " in both examples
s. 98 - mathematicians often use a period “.” or a comma “,”; ... the last -> " <- is not written with normal "style" :O
s.100 - {3, 7, 911, 13, 15}: ... missing " , " between 9 and 11
s.111 - The first thing we need in our class is a feature representing the line to be built. ... "We call it (the feature) fancy_line... but the feature is " build_a_line " i guess
We call it fancy_line.
s.121 - line_exists: s /= Void ... line_exists: l /= Void
s.125 - instruction as executed by clients is jot just create stop1 ... jot ? ^^
s.125 - line_exists: s /= Void ... line_exists: l /= Void
s.128 - 1 • he precondition of its creation procedure. ... missing " T "
s.132 - One immediate question is how > you will you < specify the root class and root creation procedure of a system.
s.134 - This is true of unqualified calls: ... true for ?
s.136 - made of components to be developed autonomously and combined in may different ways. ... many
s.141 - 687 + 42 = 29 ... 729
s.146 - It is the control structure we have been using implicitly in all the examples so far, ... they would be executed (i guess)
since we have been writing instructions under the assumption that they would executed in the order given.
s.151 - full.extend (metro_1)] ... " ] "
s.152 - this is true in both its “” and its “”. ... its what?
s.162 - Afterexecution ... After execution
s.163 - If you have ever try to use a program only to see it “hang”, it might very ... tried
s.171 - Of course this convention is not there by accident, but intended ... to ensure ?
precisely ensure that the typical iteration scheme on a list
s.183 - chosen by the programmer, who lets the compiler maps them to memory ... lets the compiler map them
locations.
s.192 - part of the loop, The loop correctness rules ... , T
s.195 - interations ... (maybe iteration?)
s.195 - In the discussion of data structures.we will see that it is possible, without ... " . " ... " constrol " ... " to to " new constrol constructs, to to define powerful iterators applicable to a wide range of object structures.
s.197 - In addition, as yo may have ... you
s.199 - The rationale for this policy—which may appear surprising at first—is that a ... " lists " maybe ?! Multi-branch explicitly list a set of expected cases and their desired treatment.
s.208 - The last example of our study of conditionals provide a good case for defining ... " provides "
a “functional abstraction” in the form of a routine.