I see no reason why interfaces shouldn’t provide methods themselves. If
they can provide methods, why shouldn’t it be possible to add a utility
method to an interface (such that it would work with any compliant
object) to perform a specific job which is not otherwise catered for by
the interface?
If you take Enumerable as an example of an existing Ruby interface, you
know that adding a method to Enumerable affects arrays, hashes, ranges
and more. This I like. It means that I can add a method to Enumerable
that logically belongs in Enumerable, rather than having, in effect, a
method lying around in another class which only operates on Enumerable
objects, but which claims to be a member of a completely unrelated
class.
Changing the required functions for an interface should be a no-no, but
it would serve little or no point anyway.
All in all, I would advocate the approach (which seems rubyish to me) of
assuming that the programmer knows what they’re doing and if they wish
to modify an interface letting them do it.
TTFN,
Geoff.
···
On Fri, Nov 21, 2003 at 10:52:19PM +0900, Greg McIntyre wrote:
It occured to me on the bus today…
Can interfaces be changed at run-time? I think they shouldn’t because
allowing interfaces to be updated any time after they’ve been created
would mean that every object implementing the interface would have to
be re-checked. Maybe one could iterate (or some faster search) through
the object space (ObjectSpace), but it seems better avoided.
So this should be an error:
interface IFoo
# some stuff
end
…
interface IFoo
# add more stuff to IFoo
end # => Error, redefinition of interface IFoo
The reason I say this is because it works differently to the way Ruby
classes work in a similar situation. It therefore has baring on
deriving interfaces from classes implicitly (which I’m still thinking
about, a little bit). However if you do it explicitly and optionally,
on a particular line of code, I think you’re fine because you choose
at which point to grab the class’s interface.