In response to the latest reprint request from Addison-Wesley, I updated
the errata list for EC++. Below are the latest changes (in my usual "sort
of HTML" format).
Scott
DATE DATE
REPORTED WHO PAGES WHAT FIXED
-------- --- ----- ------------------------------------------------ --------
5/16/04 md 77 "an intuitive semantics" ==> "intuitive
8/15/04
semantics"
5/16/04 md 83 "minimalness" ==> "minimality"
8/15/04
244
7/ 7/04 al 205 valueDelimOpen and valueDelimClose should be
8/15/04
declared private in MyPerson, because clients
should not be able to call them. They're just an
implementation detail of the class.
Interesting Comments:
DATE
REPORTED WHO PAGES WHAT
-------- --- ------- ----------------------------------------------------------
7/21/04 am 179-180 Another way to deal with the need to downcast if you can't
redefine allAccounts or BankAccount is to declare
something like NewBankAccount as a sibling class to
SavingsAccount and CheckingAccount, then adopt a policy of
deriving new classes only from NewBankAccount. You'll
still have to downcast from BankAccount to Savings-,
Checking-, or NewBankAccount, but once you're in
NewBankAcount, you can use a virtual creditInterest.
Sunday, August 15, 2004
Friday, August 13, 2004
Request for comments on extended "Easy to use correctly, hard to use incorrectly"
I'm working on materials for my upcoming full-day seminar, "Better Software --
No Matter What," (see http://www.aristeia.com/seminars_frames.html for scheduled
offerings) and I've put together a draft of the portion of the seminar on the
guideline, "Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly."
This is essentially an extended version of the arguments I advance in my recent
IEEE Software article (
http://www.aristeia.com/Papers/IEEE_Software_JulAug_2004.pdf).
The materials include a number of examples of interfaces that violate the
guideline, but I'm interested in other examples, because too many of mine are
drawn from C++ and Windows. (The talk is language- and platform-independent.)
If you have time and interest, I'd appreciate it if you'd take a look at the
materials at http://www.aristeia.com/Personal/easyhard.pdf and let me know if
you have any other examples that would reinforce my points. If you have other
comments on the materials in general, I'd welcome those, too.
Thanks very much for your help in my campaign to identify ways for programmers
to improve software quality.
Scott
No Matter What," (see http://www.aristeia.com/seminars_frames.html for scheduled
offerings) and I've put together a draft of the portion of the seminar on the
guideline, "Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly."
This is essentially an extended version of the arguments I advance in my recent
IEEE Software article (
http://www.aristeia.com/Papers/IEEE_Software_JulAug_2004.pdf).
The materials include a number of examples of interfaces that violate the
guideline, but I'm interested in other examples, because too many of mine are
drawn from C++ and Windows. (The talk is language- and platform-independent.)
If you have time and interest, I'd appreciate it if you'd take a look at the
materials at http://www.aristeia.com/Personal/easyhard.pdf and let me know if
you have any other examples that would reinforce my points. If you have other
comments on the materials in general, I'd welcome those, too.
Thanks very much for your help in my campaign to identify ways for programmers
to improve software quality.
Scott
Subscribe to:
Posts (Atom)