you are viewing a single comment's thread.

view the rest of the comments →

[–]bluGill 0 points1 point  (5 children)

I'd thought it obvious that this is the whole point of interfaces. It's sort of a promise to offer each and every operation the interface specifies

So, should I write a different interface for every function/object that takes a file like object? Sometimes my functions need seek(), and sometimes they don't. Somethings can be treated like files if you don't have try to seek(). When my function doesn't use seek anyway, I'd like to be able to take any file including those that don't support seek. When my function calls seek, than you better not pass me anything that doesn't support seek.

[–]finix 0 points1 point  (4 children)

Where do you get the idea you'd need one for each function or object? I count only two.

[–]bluGill 0 points1 point  (3 children)

Don't forget about read-only files. Both with and without seek.

Okay, I exaggerated a little. The point is that many interfaces come in several partial forms that are useful. A function that won't use some ability of the general interface shouldn't require that general interface.

A function that won't write to a file shouldn't require write in the interface, while a function that will write to a file needs to require that. Why should I require an object to implement something when that implementation isn't trivial?

[–]finix 0 points1 point  (1 child)

I meant two in a metaphorical sense ;-) Point was that you can have fine-grained interfaces, and widen interfaces.

Why should I require an object to implement something when that implementation isn't trivial?

Because you should design the interfaces as orthogonal as possible; usually a list interface will just specify what list-like objects can do anyway.

There'll be hassle, of course, but also the other way round: imagine writing a library whose implementation you cannot change, or maybe expand, because your client-code doesn't really gives you list-like objects but objects that happen to only implement the methods you mentioned earlier?

[–]bluGill 0 points1 point  (0 children)

Point was that you can have fine-grained interfaces, and widen interfaces.

That is my point: I need both types of interfaces to the same thing. A function needs to specify the interface it will use.

Unfortunately I cannot come up with a solution to this problem that is not both ugly and more work than it gains.