Interfaces...

[Carson Gross]

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
>
>