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