Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #8590 > unrolled thread

in praise of type checking

Back to article view | Back to comp.lang.java.programmer

Contents

  in praise of type checking Roedy Green <see_website@mindprod.com.invalid> - 2011-10-05 23:33 -0700
    Re: in praise of type checking Lew <lewbloch@gmail.com> - 2011-10-06 06:43 -0700
      Re: in praise of type checking Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-10-06 09:52 -0700
      Re: in praise of type checking Roedy Green <see_website@mindprod.com.invalid> - 2011-10-07 12:43 -0700
        Re: in praise of type checking Gene Wirchenko <genew@ocis.net> - 2011-10-07 14:57 -0700
        Re: in praise of type checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-07 20:18 -0400
    Re: in praise of type checking Robert Klemme <shortcutter@googlemail.com> - 2011-10-06 22:31 +0200
      Re: in praise of type checking Roedy Green <see_website@mindprod.com.invalid> - 2011-10-07 12:36 -0700
        Re: in praise of type checking Robert Klemme <shortcutter@googlemail.com> - 2011-10-08 16:05 +0200
          Re: in praise of type checking Lew <lewbloch@gmail.com> - 2011-10-08 09:35 -0700
            Re: in praise of type checking Robert Klemme <shortcutter@googlemail.com> - 2011-10-11 07:48 +0200
              Re: in praise of type checking Gene Wirchenko <genew@ocis.net> - 2011-10-11 13:04 -0700
              Re: in praise of type checking Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-10-11 17:52 -0300
                Re: in praise of type checking Patricia Shanahan <pats@acm.org> - 2011-10-12 01:49 +0100
                  Re: in praise of type checking Gene Wirchenko <genew@ocis.net> - 2011-10-11 19:12 -0700
              Re: in praise of type checking Lew <lewbloch@gmail.com> - 2011-10-11 19:10 -0700
    Re: in praise of type checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-06 20:29 -0400
      Re: in praise of type checking Robert Klemme <shortcutter@googlemail.com> - 2011-10-06 23:56 -0700
        Re: in praise of type checking Gunter Herrmann <notformail0106@earthlink.net> - 2011-10-07 13:57 -0400
    Re: in praise of type checking Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-10-07 07:19 -0300
      Re: in praise of type checking Roedy Green <see_website@mindprod.com.invalid> - 2011-10-07 12:39 -0700
        Re: in praise of type checking Gene Wirchenko <genew@ocis.net> - 2011-10-07 15:03 -0700
          Space probes was Re: in praise of type checking Tom Anderson <twic@urchin.earth.li> - 2011-10-11 19:26 +0100
            Re: Space probes was Re: in praise of type checking Leif Roar Moldskred <leifm@dimnakorr.com> - 2011-10-12 01:15 -0500
              Re: Space probes was Re: in praise of type checking Travers Naran <tnaran@gmail.com> - 2011-10-12 07:23 -0700
              Re: Space probes was Re: in praise of type checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-12 20:04 +0000
              Re: Space probes was Re: in praise of type checking Gene Wirchenko <genew@ocis.net> - 2011-10-12 13:53 -0700
                Re: Space probes was Re: in praise of type checking Leif Roar Moldskred <leifm@dimnakorr.com> - 2011-10-12 16:55 -0500
                  Re: Space probes was Re: in praise of type checking Gene Wirchenko <genew@ocis.net> - 2011-10-12 15:02 -0700
                    Re: Space probes was Re: in praise of type checking Leif Roar Moldskred <leifm@dimnakorr.com> - 2011-10-13 00:08 -0500
                      Re: Space probes was Re: in praise of type checking Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-10-13 07:48 -0300
                        Re: Space probes was Re: in praise of type checking "John B. Matthews" <nospam@nospam.invalid> - 2011-10-14 07:09 -0400
                  Re: Space probes was Re: in praise of type checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-12 22:03 +0000
              Re: Space probes was Re: in praise of type checking Tom Anderson <twic@urchin.earth.li> - 2011-10-14 14:14 +0100
    Re: in praise of type checking RedGrittyBrick <RedGrittyBrick@spamweary.invalid> - 2011-10-07 11:50 +0100
      Re: in praise of [loosey goosey] type checking) RedGrittyBrick <RedGrittyBrick@spamweary.invalid> - 2011-10-07 12:20 +0100
    Re: in praise of type checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-10-07 14:00 +0000
      Re: in praise of type checking Arne Vajhøj <arne@vajhoej.dk> - 2011-11-06 17:32 -0500

Page 2 of 2 — ← Prev page 1 [2]

#8640

On Fri, 07 Oct 2011 07:19:32 -0300, Arved Sandstrom
<asandstrom3minus1@eastlink.ca> wrote, quoted or indirectly quoted
someone who said :

>I don't myself see the awfulness inherent in *me*
>having to check that all the uses of a changed method are still correct.

It is not about having to check, it is about feeling confident the
final work is perfect.  It does not rely on me being perfect. This
sort of work is very tedious. To catch an error by proofreading or by
debugging takes much much longer than having the type system check for
you.  And further, no matter how much checking you do, you still are
not 100% sure it is correct.

-- 
Roedy Green Canadian Mind Products
http://mindprod.com
It should not be considered an error when the user starts something
already started or stops something already stopped. This applies
to browsers, services, editors... It is inexcusable to 
punish the user by requiring some elaborate sequence to atone,
e.g. open the task editor, find and kill some processes.

[toc] | [prev] | [next] | [standalone]

#8645

On Fri, 07 Oct 2011 12:39:22 -0700, Roedy Green
<see_website@mindprod.com.invalid> wrote:

>On Fri, 07 Oct 2011 07:19:32 -0300, Arved Sandstrom
><asandstrom3minus1@eastlink.ca> wrote, quoted or indirectly quoted
>someone who said :
>
>>I don't myself see the awfulness inherent in *me*
>>having to check that all the uses of a changed method are still correct.
>
>It is not about having to check, it is about feeling confident the
>final work is perfect.  It does not rely on me being perfect. This
>sort of work is very tedious. To catch an error by proofreading or by
>debugging takes much much longer than having the type system check for
>you.  And further, no matter how much checking you do, you still are
>not 100% sure it is correct.

     One never is, anyway, but why take chances?

     I like what Hoare said about it: "The story of the Mariner space
rocket to Venus, lost because of the lack of compulsory declarations
in FORTRAN, was not to be published until later. I was eventually
persuaded of the need to design programming notations so as to
maximize the number of errors which cannot be made, or if made, can be
reliably detected at compile time. Perhaps this would make the text of
programs longer. Never mind! Wouldn’t you be delighted if your Fairy
Godmother offered to wave her wand over your program to remove all its
errors and only made the condition that you should write out and key
in your whole program three times! The way to shorten programs is to
use procedures, not to omit vital declarative information."

     I also like: "There are two ways of constructing a software
design: One way is to make it so simple that there are obviously no
deficiencies, and the other way is to make it so complicated that
there are no obvious deficiencies. The first method is far more
difficult."

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#8712 — Space probes was Re: in praise of type checking

On Fri, 7 Oct 2011, Gene Wirchenko wrote:

>     I like what Hoare said about it: "The story of the Mariner space 
> rocket to Venus, lost because of the lack of compulsory declarations in 
> FORTRAN, was not to be published until later.

I love Tony Hoare.

But anyway, it occurred to me that there are a remarkable number of good 
stories about space probes, and space rockets, which are specifically 
relevant to getting things right (or rather, wrong) when programming. The 
ones i know:

- Mariner 1 and "The most expensive hyphen in history"
- Mars Climate Orbiter and metric vs imperial units
- Ariane 5 and exception handling, data typing, scope creep, and unit testing
- Eagle and the 1201 alarms [1]
- I vaguely remember a story about a computer controlling a landing 
(during a test) which followed a descent trajectory defined by 
interpolating a polynomial; the points defining the polynomial made a nice 
smooth line, but the thing about high-order polynomials is that the 
interpolation between them can be pretty wild - in this case, the minimum 
altitude reached by the curve was below ground level
- Er ...
- That's it.

Any others?

tom

[1] On which subject:

http://www.hq.nasa.gov/alsj/a11/a11.1201-pa.html
http://www.hq.nasa.gov/alsj/a11/a11.1201-fm.html
http://www.doneyles.com/LM/Tales.html

-- 
NOW ALL ASS-KICKING UNTIL THE END

[toc] | [prev] | [next] | [standalone]

#8733 — Re: Space probes was Re: in praise of type checking

Tom Anderson <twic@urchin.earth.li> wrote:
>
> - Ariane 5 and exception handling, data typing, scope creep, and unit testing

The Ariane 5 incident doesn't tell us anything about exception
handling, data typing, scope creep or unit testing. Neither of those
were the culprit. It _does_ tell us a few things about requirements / 
specification (mis-)management.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#8736 — Re: Space probes was Re: in praise of type checking

On 11/10/2011 11:15 PM, Leif Roar Moldskred wrote:
> Tom Anderson<twic@urchin.earth.li>  wrote:
>>
>> - Ariane 5 and exception handling, data typing, scope creep, and unit testing
>
> The Ariane 5 incident doesn't tell us anything about exception
> handling, data typing, scope creep or unit testing. Neither of those
> were the culprit. It _does_ tell us a few things about requirements /
> specification (mis-)management.

I thought it told us the importance of not dumping your exceptions to 
stdout when stdout is fed into the rocket gimbal controller?

[toc] | [prev] | [next] | [standalone]

#8738 — Re: Space probes was Re: in praise of type checking

On Wed, 12 Oct 2011 01:15:13 -0500, Leif Roar Moldskred wrote:

> Tom Anderson <twic@urchin.earth.li> wrote:
>>
>> - Ariane 5 and exception handling, data typing, scope creep, and unit
>> testing
> 
> The Ariane 5 incident doesn't tell us anything about exception handling,
> data typing, scope creep or unit testing. Neither of those were the
> culprit. It _does_ tell us a few things about requirements /
> specification (mis-)management.
>
True enough, but it speaks volumes about skimping on integration testing 
and not bothering to test edge conditions.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#8739 — Re: Space probes was Re: in praise of type checking

On Wed, 12 Oct 2011 01:15:13 -0500, Leif Roar Moldskred
<leifm@dimnakorr.com> wrote:

>Tom Anderson <twic@urchin.earth.li> wrote:
>>
>> - Ariane 5 and exception handling, data typing, scope creep, and unit testing
>
>The Ariane 5 incident doesn't tell us anything about exception
>handling, data typing, scope creep or unit testing. Neither of those
>were the culprit. It _does_ tell us a few things about requirements / 
>specification (mis-)management.

     AIUI, it had to do with a type conversion that lost precision.
Either the exception was not thrown or was not handled.  (My sources
did not go into that detail.)

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#8740 — Re: Space probes was Re: in praise of type checking

Gene Wirchenko <genew@ocis.net> wrote:
> 
>     AIUI, it had to do with a type conversion that lost precision.
> Either the exception was not thrown or was not handled.  (My sources
> did not go into that detail.)

Yes ... but not really. The error manifested as an arithmetic overflow
exception in the hardware, but that is an immaterial detail. The
_actual_ problem didn't have anything to do with exception handling or
even with programming errors.

What had happened was that that they took a piece of code that had
been written for the Ariane 4 rocket -- and which was correct and
without defects -- and put it onto the much larger and more powerful
Ariane 5 rocket without considering if the code was fit for its new
purpose and without testing the way the code interacted with the rest
of the system.

It was the wrong code, but there was nothing wrong _with_ the code:
like a traffic cop trying to measure the speed of a passing car with a
hair dryer -- there's nothing wrong _with_ the hair dryer, but the
hair dryer is clearly the wrong choice.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#8741 — Re: Space probes was Re: in praise of type checking

On Wed, 12 Oct 2011 16:55:39 -0500, Leif Roar Moldskred
<leifm@dimnakorr.com> wrote:

[snip]

>It was the wrong code, but there was nothing wrong _with_ the code:
>like a traffic cop trying to measure the speed of a passing car with a
>hair dryer -- there's nothing wrong _with_ the hair dryer, but the
>hair dryer is clearly the wrong choice.

     Sure there was.  It had an assumption about how much oomph the
rocket had.  The Ariane 5 had way more than the 4 did.  With the 4,
the overflow was not possible.  With the 5, it was.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#8751 — Re: Space probes was Re: in praise of type checking

Gene Wirchenko <genew@ocis.net> wrote:
> 
>     Sure there was.  It had an assumption about how much oomph the
> rocket had.  The Ariane 5 had way more than the 4 did.  With the 4,
> the overflow was not possible.  With the 5, it was.

Yes, but as the code wasn't written to be used on the Ariane 5, that
was a valid assumption and not an error. The code was correct and fit
for its intended use. That someone later took this code and tried to
use it for something it was never meant to be used for is not an error
in the code: A wrench makes a poor hammer, but that doesn't mean the
wrench is constructed badly.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#8757 — Re: Space probes was Re: in praise of type checking

On 11-10-13 02:08 AM, Leif Roar Moldskred wrote:
> Gene Wirchenko <genew@ocis.net> wrote:
>>
>>     Sure there was.  It had an assumption about how much oomph the
>> rocket had.  The Ariane 5 had way more than the 4 did.  With the 4,
>> the overflow was not possible.  With the 5, it was.
> 
> Yes, but as the code wasn't written to be used on the Ariane 5, that
> was a valid assumption and not an error. The code was correct and fit
> for its intended use. That someone later took this code and tried to
> use it for something it was never meant to be used for is not an error
> in the code: A wrench makes a poor hammer, but that doesn't mean the
> wrench is constructed badly.
> 
When I read the report that Martin pointed us at, particularly pages 4-6
(pages 8-10 of the PDF), I sure don't get the impression that the code
was "correct and fit for its intended use". This includes in a wider
sense the documentation that describes the assumptions and decisions
related to the code.

How do you know that the code was not meant to be used for the Ariane 5?
They _did_ use it for the Ariane 5; that's enough evidence for me that
they intended for it to be used not just for the Ariane 4 but also for
the Ariane 5. The report clearly states that the reasoning related to
the horizontal bias variable BH was *faulty* - they just happened to be
fortunate with Ariane 4. It was not, as you suggest, a "valid
assumption". And the follow-up exception-handling was described as a
systematic software design error.

In a wider sense, if you've got a codebase that was intended for
situation A (or more precisely, since "intended" is a strong purposeful
word that implies knowing what you're about, "used with"), and now you
adopt it for situation B, that codebase _belongs_ to situation B. You
can't say it's fit and correct just because it still works in situation
A - who cares, actually? If it's unfit for situation B it's unfit for
situation B. Period.

AHS
-- 
I tend to watch a little TV... Court TV, once in a while. Some of the
cases I get interested in.
-- O. J. Simpson

[toc] | [prev] | [next] | [standalone]

#8782 — Re: Space probes was Re: in praise of type checking

In article <amzlq.8514$kJ5.8234@newsfe03.iad>,
 Arved Sandstrom <asandstrom3minus1@eastlink.ca> wrote:

> On 11-10-13 02:08 AM, Leif Roar Moldskred wrote:
> > Gene Wirchenko <genew@ocis.net> wrote:
> >>
> >> Sure there was.  It had an assumption about how much oomph the 
> >> rocket had.  The Ariane 5 had way more than the 4 did.  With the 
> >> 4, the overflow was not possible.  With the 5, it was.
> > 
> > Yes, but as the code wasn't written to be used on the Ariane 5, 
> > that was a valid assumption and not an error. The code was correct 
> > and fit for its intended use. That someone later took this code and 
> > tried to use it for something it was never meant to be used for is 
> > not an error in the code: A wrench makes a poor hammer, but that 
> > doesn't mean the wrench is constructed badly.
> > 
> When I read the report that Martin pointed us at, particularly pages 
> 4-6 (pages 8-10 of the PDF), I sure don't get the impression that the 
> code was "correct and fit for its intended use". This includes in a 
> wider sense the documentation that describes the assumptions and 
> decisions related to the code.
> 
> How do you know that the code was not meant to be used for the Ariane 
> 5? They _did_ use it for the Ariane 5; that's enough evidence for me 
> that they intended for it to be used not just for the Ariane 4 but 
> also for the Ariane 5. The report clearly states that the reasoning 
> related to the horizontal bias variable BH was *faulty* - they just 
> happened to be fortunate with Ariane 4. It was not, as you suggest, a 
> "valid assumption". And the follow-up exception-handling was 
> described as a systematic software design error.

I inferred that BH was left unprotected to reduce delay in the "event of 
a hold in the count-down," a feature used in Ariane 4. "The same 
requirement does not apply to Ariane 5." The "systematic software design 
error" was a culture of "only addressing random hardware failures." The 
management error was in not thoroughly testing the reused software.
 
> In a wider sense, if you've got a codebase that was intended for 
> situation A (or more precisely, since "intended" is a strong 
> purposeful word that implies knowing what you're about, "used with"), 
> and now you adopt it for situation B, that codebase _belongs_ to 
> situation B. You can't say it's fit and correct just because it still 
> works in situation A - who cares, actually? If it's unfit for 
> situation B it's unfit for situation B. Period.

A Java analogy might be adopting a 10 year old external dependency 
without running _all_ unit tests.

"No reference to justification of [the BH] decision was found directly 
in the source code." I can't help but think that generated documentation 
(e.g javadoc, adahtml) is one way to mitigate this kind of risk.

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[toc] | [prev] | [next] | [standalone]

#8742 — Re: Space probes was Re: in praise of type checking

On Wed, 12 Oct 2011 16:55:39 -0500, Leif Roar Moldskred wrote:

> Gene Wirchenko <genew@ocis.net> wrote:
>> 
>>     AIUI, it had to do with a type conversion that lost precision.
>> Either the exception was not thrown or was not handled.  (My sources
>> did not go into that detail.)
> 
> Yes ... but not really. The error manifested as an arithmetic overflow
> exception in the hardware, but that is an immaterial detail. The
> _actual_ problem didn't have anything to do with exception handling or
> even with programming errors.
> 
> What had happened was that that they took a piece of code that had been
> written for the Ariane 4 rocket -- and which was correct and without
> defects -- and put it onto the much larger and more powerful Ariane 5
> rocket without considering if the code was fit for its new purpose and
> without testing the way the code interacted with the rest of the system.
> 
> It was the wrong code, but there was nothing wrong _with_ the code: like
> a traffic cop trying to measure the speed of a passing car with a hair
> dryer -- there's nothing wrong _with_ the hair dryer, but the hair dryer
> is clearly the wrong choice.

The full report, which makes interesting reading, is here:
http://esamultimedia.esa.int/docs/esa-x-1819eng.pdf



-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#8785 — Re: Space probes was Re: in praise of type checking

On Wed, 12 Oct 2011, Leif Roar Moldskred wrote:

> Tom Anderson <twic@urchin.earth.li> wrote:
>
>> - Ariane 5 and exception handling, data typing, scope creep, and unit testing
>
> The Ariane 5 incident doesn't tell us anything about exception handling, 
> data typing, scope creep or unit testing. Neither of those were the 
> culprit. It _does_ tell us a few things about requirements / 
> specification (mis-)management.

It tells us about all those things, which is why i mentioned them. And 
more - i should also have mentioned process management.

The fundamental failure was about requirements, absolutely. That's what i 
referred to as scope creep - the scope of the inertial navigation system 
was originally defined as being Ariane 4, but crept to include Ariane 5, 
without this being properly addressed.

But that was not the only failure. There were several points at which 
something could have been done differently which would have saved the 
rocket. Off the top of my head:

1. The module that failed was a pre-launch calibration daemon in the 
inertial navigation system; it had no use at all after launch. If it had 
been shut down at launch, the failure would not have occurred.

2. IIRC, the pre-launch procedure had changed such that the daemon was not 
needed anyway. If it had been removed, the failure would not have 
occurred.

3. The failure involved a cast from (in Java terms) a double (used to 
capture and instrument reading) to a short (used for calculations) which 
overflowed. If doubles had been used for calculation, the failure would 
not have occurred.

4. The cast was not protected by a suitable exception handler. If it had 
been (although i'm not sure what the handler would actually do), the 
failure would not have occurred.

5. The inertial navigation system's top-level exception handling handled a 
crash by writing diagnostic information to the same data bus used for 
output, without any metadata indicating that it was diagnostics rather 
than data; the guidance computer interpreted it as data, and went wild. If 
the diagnostic information had been written elsewhere, or had been marked 
and subsequently recognised by the guidance computer as being such rather 
than data, the failure would not have occurred.

6. The combination of a real inertial navigation system and a real 
guidance computer was never tested with real sensor inputs. The guidance 
computer was tested with a mock inertial navigation system, which did not 
accurately reproduce the real system's faulty behaviour. It was a unit 
test rather than an integration test. If the test had been an integration 
test, the fault would have been detected long before launch, and the 
failure would not have occurred.

Yes, you can identify a root cause, in the form of a mistake in the 
requirements process. But you can also identify a series of other mistakes 
which enabled that mistake to cause the failure. To pay attention only to 
the root cause and discard the other mistakes is foolish.

tom

-- 
Re-enacting the future

[toc] | [prev] | [next] | [standalone]

#8621

On 06/10/2011 07:33, Roedy Green wrote:
> I changed the result of a widely used method from boolean to int.  The
> neat thing was the compiler (actually the Intellij syntax checker)
> made sure I fixed up every invocation of that method. It would not let
> me forget even  one.
>
> Imagine a language with loosey goosey type checking where it was
> entirely up to you entirely to ensure all the invocations were
> corrected.  You could never be sure.

The problem might not arise. Depending on which language you mean and 
how you apply your knowledge of the language to the intended use of the 
method.

For example, in Perl, if I changed a method so that it returned an 
integer instead of a boolean I would do so in such a way that any 
existing code calling that method could continue to function unchanged. 
Perl can quite happily treat any integer as a boolean, I would just have 
to ensure that I return an integer value that will be treated as (say) 
false under circumstances where the original method would have been 
expected to return false.

In general I suspect it is rare to change a method's return value so 
radically. I'd be much more likely to create a new method with a new 
name and have one method call the other for the bulk of it's processing. 
In other words, make one method a wrapper for the other (to eliminate as 
much duplication of code as is sensibly possible).

I like strict typing but I don't think your example is an especially 
good justification of it. It could be used to support the opposite 
contention.

-- 
RGB

[toc] | [prev] | [next] | [standalone]

#8622 — Re: in praise of [loosey goosey] type checking)

On 07/10/2011 11:50, RedGrittyBrick wrote:
> On 06/10/2011 07:33, Roedy Green wrote:
>> I changed the result of a widely used method from boolean to int. The
>> neat thing was the compiler (actually the Intellij syntax checker)
>> made sure I fixed up every invocation of that method. It would not let
>> me forget even one.
>>
>> Imagine a language with loosey goosey type checking where it was
>> entirely up to you entirely to ensure all the invocations were
>> corrected. You could never be sure.
>
> The problem might not arise. Depending on which language you mean and
> how you apply your knowledge of the language to the intended use of the
> method.
>
> For example, in Perl, if I changed a method so that it returned an
> integer instead of a boolean I would do so in such a way that any
> existing code calling that method could continue to function unchanged.
> Perl can quite happily treat any integer as a boolean, I would just have
> to ensure that I return an integer value that will be treated as (say)
> false under circumstances where the original method would have been
> expected to return false.

To illustrate:

Let's say I have an object "store" and I have a method "contains()" that 
takes an argument and returns boolean telling us if the store contains a 
matching element. I might use it thusly in a zillion places

     if ($store.contains($APPLE)) {
       $store.sell($APPLE);
     } else {
       die "Out of $APPLE!";
     }

Now lets say I change contains() to return a count instead of a boolean.

My zillions of places treating the return value as boolean still work 
unchanged. Hurrah for loosey goosey!

-- 
RGB

[toc] | [prev] | [next] | [standalone]

#8624

Roedy Green <see_website@mindprod.com.invalid> wrote:
> I changed the result of a widely used method from boolean to int.  The
> neat thing was the compiler (actually the Intellij syntax checker)
> made sure I fixed up every invocation of that method. It would not let
> me forget even  one. 

So I presume you didn't have anything like this in your code:

{
   foo(yourMethodToChangeToInt());
}
void foo(int i) { ... }
void foo(boolean b) { ... }
boolean yourMethodToChangeToInt() { ... }

After the change, the other foo will be called.
The point is, that the compiler won't necessarily present
you *all* call-sites of your method, not even all those
where the result is actually used.

[toc] | [prev] | [next] | [standalone]

#9687

On 10/7/2011 10:00 AM, Andreas Leitgeb wrote:
> Roedy Green<see_website@mindprod.com.invalid>  wrote:
>> I changed the result of a widely used method from boolean to int.  The
>> neat thing was the compiler (actually the Intellij syntax checker)
>> made sure I fixed up every invocation of that method. It would not let
>> me forget even  one.
>
> So I presume you didn't have anything like this in your code:
>
> {
>     foo(yourMethodToChangeToInt());
> }
> void foo(int i) { ... }
> void foo(boolean b) { ... }
> boolean yourMethodToChangeToInt() { ... }
>
> After the change, the other foo will be called.
> The point is, that the compiler won't necessarily present
> you *all* call-sites of your method, not even all those
> where the result is actually used.

Which is another good reason not to change the return
type but add a new method.

Arne

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web