[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-nio-dev
Subject:    Interfaces...
From:       cgross () guidewire ! com (Carson Gross)
Date:       2009-06-22 21:44:38
Message-ID: 7D3007CC2DAF25499C28D1C0DDE693DA01AA5CFF () newexchange ! guidewire ! com
[Download RAW message or body]

Of course there are tradeoffs.  I still think that an interface, coupled with a solid \
base class for the 90% use cases, is the right thing.  If someone doesn't extend the \
base class because there implementation is sufficiently different, then they *should* \
have to think about the new method.  I regard that as a feature of interfaces, not a \
shortcoming.

Anyway, I'm sure you all know all this.  I'm just registering my \
random-guy-on-teh-internets opinion: I'd like interfaces.  At the same time, an \
abstract class is a huge step forward from the old library.

I'll go away now.

Cheers,
Carson

-----Original Message-----
From: R?mi Forax [mailto:forax at univ-mlv.fr] 
Sent: Monday, June 22, 2009 1:21 PM
To: Carson Gross
Cc: Mark Thornton; nio-dev at openjdk.java.net
Subject: Re: Interfaces...

Interfaces are not really future proof,
at least until we have extension methods,
you can't add a new method to an interface without breaking
the backward compatibility.

By example, Reader is an abstract class defined in 1.1,
this had allowed read(CharBuffer) to be introduced in 1.5. **

R?mi

Carson Gross a ?crit :
> Ah, right.  Didn't catch that.  I'd still advocate for an interface, so
> you don't have to corner yourself in an inheritance hierarchy.
> 
> Still, infinitely better than File.
> 
> Cheers,
> Carson
> 
> -----Original Message-----
> From: Mark Thornton [mailto:mthornton at optrak.co.uk] 
> Sent: Monday, June 22, 2009 12:43 PM
> To: Carson Gross
> Cc: nio-dev at openjdk.java.net
> Subject: Re: Interfaces...
> 
> Carson Gross wrote:
> 
> > All
> > 
> > 
> > 
> > I'm not on list, so feel free to ignore me, but I'd like to ask that 
> > you consider extracting interfaces for the core classes in the nio2 
> > library.  For example,
> > 
> > 
> > 
> > java.nio.file.Path
> > 
> > 
> > 
> > should have a corresponding interface, with the same methods at Path, 
> > so that people can write code against the interface, rather than the 
> > implementation.  This would facilitate testing against a file system, 
> > a notoriously touchy problem when dealing with disks, and would give 
> > people the opportunity to provide innovative implementations of the 
> > interface (e.not-so-g. putting up a path-based representation of 
> > processes.)
> > 
> > 
> > 
> > The package will be a lot more flexible if you make this simple
> > 
> change.
> 
> > 
> > 
> > Cheers,
> > Carson
> > 
> > 
> Given that Path, FileSystem and FileStore for example are abstract with 
> all methods also abstract, this is already possible.
> 
> Mark Thornton
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]