Peter, I still don't see how that'll avoid code duplication.
Let's say, for argument's sake, that a FilterInputStream's read()
method contains 4 pages of complex code. This code calls back into the
filtered stream's read method loads of times. How would we avoid
duplicating these 4 pages if we want 2 types of FilterInputStream: One
that wraps a Safe InputStream and does not throw IOException, and one
that wraps an unsafe InputStream and does throw IOException.
On Aug 20, 9:36 am, Peter Becker <peter.becker...@gmail.com> wrote:
> Here you go (three files):
>
> ===== test/Unsafe.java======
> package test;
>
> import java.io.IOException;
>
> public interface Unsafe {
> void method() throws IOException;
>
> }
>
> ===== test/Safe.java ======
> package test;
>
> public interface Safe extends Unsafe {
> void method();
>
> }
>
> =====test/Test.java=======
> package test;
>
> import java.io.IOException;
>
> public class Test {
> class UnsafeImpl implements Unsafe {
> @Override
> public void method() throws IOException {
> throw new IOException(); // ok
> }
> };
>
> class SafeImpl implements Safe {
> @Override
> public void method() {
> // can't throw here
> }
> };
>
> void method1(Unsafe unsafe) {
> unsafe.method(); // error, need to deal with exception
> }
>
> void method2(Safe safe) {
> safe.method(); // ok
> }
>
> }
>
> ==========
>
> The one trick is to realize that the safe version is actually the more
> specific one. If you think of the exception in terms of the type union
> (not accurate, but a decent analogy), then Unsafe.method() returns
> void|IOException while Safe.method() returns void, which is a more
> specific type, thus the return types are co-variant.
>
> More generally you can argue that Safe.method() makes stronger
> guarantees about its behavior than Unsafe.method(), so subtyping is
> legal. Apart from the one marked position the code above is legal Java.
>
> Peter
>
>
>
> Reinier Zwitserloot wrote:
> > On Aug 20, 12:21 am, Peter Becker <peter.becker...@gmail.com> wrote:
>
> >> No implementation would be duplicated, the safe version could be a
> >> subtype of the unsafe one. Not too many interfaces will face that
> >> problem. To me it seems much better than not distinguishing.
>
> > Can you show me how this would work?
>
> > I have a hard time seeing how you can do that without (oh, the irony),
> > employing some sort of sneakythrow mechanism.
>
> > I guess we will have to agree to disagree here, but I'm fairly sure
> > the idealism lost in allowing sneakythrow is minor, whereas the amount
> > of pain you can solve is sizable. (in practice, due to widespread bad
> > API design we all know will never ever get fixed, such as in the core
> > JDK)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
