[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More finalize woes
From: |
Tom Tromey |
Subject: |
Re: More finalize woes |
Date: |
06 Mar 2003 08:48:31 -0700 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
>>>>> "Dalibor" == Dalibor Topic <address@hidden> writes:
Dalibor> Your generator ends up with a different set of test cases for
Dalibor> Classpath and for JDK. This may not be what you want but it's
Dalibor> what you get when methods are left out ;)
This is an interesting example. I'm not so sure that what you end up
with is incorrect in a significant way, though. Or perhaps you'd
prefer to write your test generator to look at all the methods,
inherited or declared, in a given class.
Dalibor> beside, the 'least surprise' argument applies here as
Dalibor> well. If I extend Classpath's Deflater to implement my own
Dalibor> SuperfastNativeDeflater, then I'd like to rely on finalize()
Dalibor> calling end(), as the spec says.
In cases where there is a finalizer with a documented effect, I agree
we must implement it. I'm just talking about trivial finalizers -- I
think we don't need those.
Tom
- More finalize woes, Jeroen Frijters, 2003/03/04
- Re: More finalize woes, Aaron M. Renn, 2003/03/04
- Re: More finalize woes, Dalibor Topic, 2003/03/04
- Re: More finalize woes, Chris Gray, 2003/03/06
- Re: More finalize woes, Tom Tromey, 2003/03/06
- Re: More finalize woes, Sascha Brawer, 2003/03/06
- Re: More finalize woes, Artur Biesiadowski, 2003/03/06
- Re: More finalize woes, Stephen Crawley, 2003/03/06
- Re: More finalize woes, Per Bothner, 2003/03/06
- Re: More finalize woes, Stephen Crawley, 2003/03/06
- Re: More finalize woes, Stephen Crawley, 2003/03/06
- Re: More finalize woes, Per Bothner, 2003/03/06