On 5/17/06, Trustin Lee <[EMAIL PROTECTED]> wrote:
On 5/16/06, peter royal <[EMAIL PROTECTED]> wrote: > > The second design issue with IoFuture is about making it > > interface. For > > now, they are concrete classes which expose internal methods that > > change > > their state. I'd like to change them look like this: > > > > * IoFuture > > * WriteFuture (extends IoFuture) > > * MutableWriteFuture (extends WriteFuture, internal use only) > > * DefaultWriteFuture (implements MutableWriteFuture, > > internal use > > only) > > * ConnectFuture (extends IoFuture) > > * MutableConnectFuture (extends ConnectFuture, internal use only) > > * DefaultConnectFuture (implements MutableConnectFuture, > > internal > > use only) > > * CloseFuture (extends IoFuture) > > * MutableCloseFuture (extends CloseFuture, internal use only) > > * DefaultCloseFuture (implements MutableCloseFuture, > > internal use > > only) > > > > Would this be too complex? > > I like the idea, but I think the idea of the MutableXXX interfaces it > a bit much. If they're for internal use, lets wait until we need > them, and just use the DefaultXXX ones directly internally. > You're right except for WriteFuture. WriteFuture is exposed to IoFilter implementations and therefore a user can create his or her own WriteFuture implementation. Would it be inevitable to expose setWritten() to users? Then why not to other futures?
I created an issue: http://issues.apache.org/jira/browse/DIRMINA-217 I will just expose setters for now instead of creating many mutable interfaces. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
