Re: Access a private variable?
Re: Access a private variable?
- Subject: Re: Access a private variable?
- From: Ian Joyner <email@hidden>
- Date: Mon, 18 Jul 2005 13:26:20 +1000
The vague term 'bug' has a bit of history, part of which I know. It
is attributed to Admiral Grace Hopper (one of the pioneers of COBOL)
who had to find a problem in a computer in 1945. When she tracked it
down, a moth had flown into the machine causing it to malfunction.
When her manager asked her what she had been doing, she responded
"debugging the machine". Said moth is now on display in the
Smithsonian. It does seem that she said this because the term 'bug'
was already in use.
Now Bertrand Meyer in OOSC seeks to clarify the term (OOSC is one of
the clearest books on software development ever written). Meyer
admits that the term 'bug' is in widespread use because it is
reasonably descriptive. Edsgar Dijkstra was less forgiving in a paper
published in ACM's SIGCSE (Computer Science Education) in about 1987
or 88 (buried in my store room somewhere). Dijkstra sees it as a
dishonest term which software engineers use to make it seem as if a
software problem was not due to design or implementation, but to the
fact that something physical (and beyond their control) has crept
into the works, like Hopper's moth.
It's a thought provoking area, and of course in software we are
dealing with the entirely abstract in which we create supposedly
perfect worlds – part of the power of software, unlike hardware which
can go worng (like in Westworld). I still use the term bug as a bit
of descriptive language, but always with some reservations.
So don't beat each other up when talking about bugs – it is a buggy
term in itself, but it does help to understand if a problem is due to
poor design or poor implementation.
One phrase I dislike which is coming into use (OK I can only think of
one company that uses it) is 'Service Pack' which has the implication
that a computer is like a car or other mechanical device, which has
to be oiled to keep it running, and that you have to apply this
service pack in order to be a responsible owner to stop things from
deteriorating. Well the problems were already built into the system,
and so I'd be much happier with 'bug fix release' or at least
'update', rather than trying to pretend that a 'service pack' release
is something other that the vendor's fault.
Every program can be boiled down to one line - run (or double click),
which of course is a high-level abstraction. Also subclasses are used
to (stepwise) refine or extend a parent – subclassing is not usually
recommended as a 'bug fix' mechanism.
Ian
Sportstec
On 16/07/2005, at 11:54 AM, Sacha Mallais wrote:
On Jul 15, 2005, at 4:45 PM, Robert Walker wrote:
Bertrand Meyer (OOSC, 2nd Ed, p 347) would call it an error ("a
wrong decision made during the development of a... system"), but
"bug" can mean error, defect ("a property of a... system that may
cause [it] to depart from its intended behaviour") or fault ("the
event of a... system departing from its intended behaviour...").
Well unless there is more to this than I see here, I wouldn't
interpret this that way at all. "A wrong decision made during
development..." Wrong by who's option? The developer expressed
his intention in the documentation, implemented what was described
in the documentation, and the code behaves according to the
described intent. How can this be called a "bug" or "wrong
decision?"
You could argue that not including a count of the in-memory-
filtered objects was the correct decision, but I doubt many people
would agree with you. :-)
If this interpretation of "bug" is true, then it really is
impossible to write bug-free software.
Isn't that a standard comp sci litany? Every program (of
reasonable complexity) has bugs.
Corollary: the smallest program consists of a single line, which is
wrong. ;-)
You would have to implement every feature that any person could
imagine in order to be bug-free.
It certainly can be a matter of opinion what features to include in
a given class. I think it's fair to say, in this case, they should
have included a way to get the whole array of in-memory-filtered
objects; it was a bug not to include it.
Besides, isn't this why OOP exists in the first place (so
developers can add additional behavior to a class for the purpose
of extending the class's usefulness)?
The ability to be "open" (i.e. extensible) and "closed" (i.e.
stable) at the same time is a major selling point of OOP, but not
the only raison d'être. Other reasons are left as an exercise for
the reader. ;-)
So I guess this means that all subclasses are "bug fixes"
according to this definition.
A class that has a specific or intended subclass is not a bug fix:
that is called design.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden