Re: Access a private variable?
Re: Access a private variable?
- Subject: Re: Access a private variable?
- From: Robert Walker <email@hidden>
- Date: Mon, 18 Jul 2005 09:25:11 -0400
These are all excellent points. My only concern, and entire reason
my my posts, is that the term "bug" is generally understood to mean
that the behavior of a piece of software deviated from that which was
intended. This is not the case in this situation.
Use of this term may prompt some developers to, unnecessarily, avoid
using a function (or class) simply due the stigma associated with the
term "bug."
I actually agree that the behavior in question should have been
included with this particular class. But, that still doesn't make it
any sort of "error," no matter what you call it. It's an omission at
most.
This is just another case of language limitation or misunderstanding,
which is quite common.
On Jul 17, 2005, at 11:26 PM, Ian Joyner wrote:
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:
40mac.com
This email sent to email@hidden
_______________________________________________
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