Download Reference Manual
The Developer's Library for D
About Wiki Forums Source Search Contact

Ticket #1141 (closed task: fixed)

Opened 16 years ago

Last modified 16 years ago

IConduit should be reexamined

Reported by: schveiguy Assigned to: kris
Priority: normal Milestone: 1.0
Component: IO Version: trunk
Keywords: Cc:

Description

Since IConduit implements both InputStream and OutputStream, all conduits can be inputs and outputs. This sort of makes sense, except that IConduit contains both an input() and output() property that return an InputStream and an OutputStream.

Now, I checked through the source and it seems that most conduits that are actually conduits return 'this' as the result of input() and output(). However, the one exception is Buffer. But it seems odd that Buffer is an OutputStream and also returns a different OutputStream.

It just seems that in the io package, everything implements many of the interfaces in io. Which kind of defeats the purpose of having so many different interfaces. I think it might be good to reexamine if there are too many requirements for some of the interfaces by having them all be cross-implementing.

I came across this when writing the ThreadConduit class. I can't inherit from Conduit because it implements ISelectable, but it really is a Conduit, so I had to re-implement all the IConduit interface (copying a lot of the code from Conduit). Three of the functions (conduit(), input(), and output()) all return 'this'. A interface function that requires one to always just return 'this', seems unnecessary.

I might be wrong, but it just seems like something that should be looked at.

Attachments

ISelectable.patch (2.9 kB) - added by schveiguy on 06/16/08 15:24:15.
patch to move ISelectable interface to more appropriate locations instead of Conduit

Change History

06/13/08 20:37:44 changed by kris

The issue is primarily ISelectable ... we added that as a hack to enable selectors.

All Conduits in Tango are read/write, and Buffer is a special Conduit variant, implementing either a wrapper for other Conduit instances or as a standalone accumulator.

06/13/08 20:40:27 changed by kris

Keep in mind that you should have been able to inherit from Conduit instead. One way to work around the ISelector hack would have been to override it and throw an exception. Not ideal by any means, but would have saved you from reimplementing all the other stuff?

06/13/08 21:03:45 changed by kris

another note:

Buffer should return itself for input & output, so that sounds like some cruft that got left behind. The methods input() and output() themselves are legacy, and were left intact to avoid breaking existing code.

06/14/08 01:22:00 changed by schveiguy

Replying to kris:

another note: Buffer should return itself for input & output, so that sounds like some cruft that got left behind. The methods input() and output() themselves are legacy, and were left intact to avoid breaking existing code.

That all sounds like what I thought it was :) OK, so about ISelectable being on Conduit, could it be moved to DeviceConduit? I think DeviceConduit is the right place because only real OS devices are selectable. In fact, a lot of the stuff in Conduit (having a handle, etc.) really belongs in device conduit, or else there should be another abstract layer between IConduit and Conduit for things that don't have handles.

06/14/08 03:15:51 changed by kris

"In fact, a lot of the stuff in Conduit (having a handle, etc.) really belongs in device conduit"

This must be the "lot of stuff" referred to:

        abstract Handle fileHandle ();

There's just the one tiny thing in there, relating to ISelectable ... not sure what else you could possibly be referring to. As I said before, the ISelectable thing is the issue and it is a known one. See above for known workarounds :)

06/16/08 15:21:02 changed by schveiguy

d'oh! you are right :) for some reason, I thought that Conduit contained all the code to deal with the file handle, but it is actually elsewhere.

So why not remove ISelectable from Conduit, and put it on DeviceConduit and SocketConduit instead?

In fact I made this change in my local copy, and tango compiled completely. The only issue that this would cause is if people keep references to Conduits instead of any of the interfaces or the derived classes, and used a selector on those.

I'll attach the patch to this ticket.

06/16/08 15:24:15 changed by schveiguy

  • attachment ISelectable.patch added.

patch to move ISelectable interface to more appropriate locations instead of Conduit

06/16/08 17:20:23 changed by kris

thanks

08/03/08 19:15:06 changed by kris

  • status changed from new to closed.
  • resolution set to fixed.

(In [3841]) fixes #1141 :: IConduit should be reexamined

Applied patch from Schveiguy. Thanks for providing that ... now you can change your ThreadConduit? :)