Sounds like you are trying to fix something little by introducing uncertainty to the inheritance structure, which could be viewed as a bigger issue.

I don't see any issue with the current way seek() works. As long as the return code is correct, it shall not impact your ability to develop on top of it.

I agree there is nothing wrong with inheriting methods that are not implemented. You could say that seek is an abstract method of the base class which in this case has not been implemented.

It is still correct to have it in there as the base class is defining as part of an interface and saying it always must be

Now if it really bothers you then you can put in your own overridden implementation of seek() that just throws a better error like 'not relevant to this instance type'.

 
sub seek () {
die "inherited method not callable or implemented on this type of obje
+ct";

}
[download]

pg explained that this interface change was not necessary, but I'd like to point out why I think it's actually a bad thing. I do not mean to rail against you or your idea, but I think this is a situation that demonstrates an important idea about system IO in general.

First, I think it's helpful to explain that IO operations usually follow the pattern of just do it, followed by check if it succeeded. This is to prevent race conditions. If there is any time at all between when you check if you can do something, and when you actually try to do it, things could have changed. To prevent that, we just ask the operating system to do something for us. The operating system attempts to do it, and tells us if it succeeded or failed. That way, the operation is atomic. As far as we're concerned, it's one step, and thus there is no race condition.

Your proposed interface violates this pattern. You may envision the seekability as simply a flag that is turned on or off depending on the filehandle type, but there are different factors that can affect the seekability. These factors can change moment to moment, so a filehandle may be seekable in general, yet still fail to seek at a specific moment. Even with your proposed change, one would still have to check seek's return value to be absolutely sure it worked, which negates the whole point of adding the seekability check.

In short, an is_really_seekable function would invite race conditions, while presenting no descernable gain.

Thanx, that is a very lucid answer - I wasnt really happy with pg's answer a first, now I have no problems.

Update:Actually I had the drive to work to think about this and I'm less happy.

I understand this is not going to change, but the DWIM part of this still irks me.

I accept that if $io_obj->can('seek') is true I still need to check the return code of $io_obj->seek(pos,whence) because 'things can happen' (tm) like drives failing etc.

But I can't see how a stream can ever become seekable, so the true value from can() doesnt help the argument of perl DWIM.

So my final points are

• stream based IO::Handle object should not inherit from IO::Seekable (but I understand that things will stay as they are)
• I should have used my brain in the first place when I tried to seek on a stream (and I hope that becomes the default position)

use brain;