Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming: OOP and memory management

From: Michael N. Christoff (mchristoff_at_sympatico.caREMOVETHIS)
Date: 07/26/04 

Date: Mon, 26 Jul 2004 17:56:20 -0400

"Thomas Gagne" <tgagne@wide-open-west.com> wrote in message
news:WaKdneXN0JpV953cRVn-jA@wideopenwest.com...
> Michael N. Christoff wrote:
> <snip>
> > Sometimes the 'free and easy' solution is not the best. Why would I
> > sacrifice a feasibly attainable extra level of safety in my code?
Because
> > attaining that extra level is not quite as easy as skipping it? Or
because
> > I can't program as freely? These are not vacuous points, but I would
put
> > them a few notches down the list from increased _provable_ safety in my
> > client's software.
> >
>
> I must live in a vacuum. I can't imagine how one of my methods would be
> passed an object that wasn't intended in production. Probably because the
> code that calls the method was also in testing? Objects don't
accidentally
> appear in the wrong places. Cat's don't accidentally show up in
collections
> of Dog objects unless put there deliberately.
>
> I can't find any extra safety, and it can't be proved that the bugs are
there.
> It's sounds like proving a negative. My software does expand
relentlessly.
> I realize other projects may have more rigourous requirements and
> specifications than I'm accustomed to and perhaps in those cases (I
haven't
> enjoyed one of those yet) flexibility isn't required.
>
> >
> >>"In other words (and other words are always necessary) the sender is
> >>responsible, and should enjoy full freedom, for determining the
> >
> > suitability of
> >
> >>the *receiver* for accomplishing the task-at-hand. It is not the
> >
> > receiver's
> >
> >>role to 2nd-guess the sender's intentions."
> >
> >
> > This is a case of distributed knowledge. Let me ask you this: Who in
this
> > case is better equipped (has the appropriate knowledge) to determine the
> > suitability of an object for the receiver? Is it the sender? Or is it
the
> > receiver?
> >
> The sender. Their knowledge is always more current and extensible than
the
> receivers.

This makes no sense, to me at least. How is the user of some software
'always' more knowledgeable than the person who wrote it? This implies that
before you send an object to another bit of code, you have to analyze the
receiver to the point where you know more about it than the authors
themselves. Seems like a waste of time to me, when we could simply have the
receiver specify what objects are appropriate. ie: everyone takes
responsibility for their own code. Its almost a restatement of the idea
behind encapsulation. My object has a protected state and I (the receiver)
take responsibility for protecting that state. I do not pass off that
responsibility to the users of my code. Also, there is the whole issue of
the use of commercial closed source software where there is no way the
sender could be more knowledgeable about the receiver than the receiver
itself.

> Who is better equipped to determine the utility of a screwdriver,
> the screwdriver or the craftsman?

This is a bad analogy. It is one of those things where a physical analogy
does not map back into the actual situation: in this case software
development. Instead of a screwdriver consider a DVD player. Who is better
equipped to determine the suitability of a disk for a disk player, the user
or the player? Unless you intend to open the player up to the point where
'your knowledge is more current and extensible than the designers of the DVD
player', then the receiver is in a better position to decide. But just as
in software development, if this level of knowledge was required before we
could operate the typical devices we use in our daily lives, no one would
have time to get anything done. That's why encapsulation and the sharing of
responsibility are thought of so highly in OO software development.

l8r, Mike N. Christoff

Relevant Pages