I found this in my drafts, dated Feb 6 2005. I 'll just push it out now unedited. Original summary:
I thought it was clear that we should add interfaces to Python, but Phillip Eby reminded me that years ago I rejected them in favor of Abstract Base Classes (ABCs). Why? I don't remember! Which do you prefer?
I can't for the life of me remember why I would prefer ABCs over
interfaces! And even if I did remember, I believe I have changed my
mind since then.
The only argument that comes to mind is that ABCs don't require more
syntax. That's usually a strong argument in Python. But it seems
that at least two of the largest 3rd party projects in Python (Zope
and Twisted) have already decided that they can't live without
interfaces, and have created their own implementation. From this I
conclude that there's a real need.
But if they can do it themselves (albeit with some heavy-duty
metaclass magic), doesn't that prove we don't have to add them to the
language? Not at all. The mechanisms used are ideosyncratic,
fragile, and cumbersome. For example, you have to use __xxx__ words
to declare conformance to an interface. Plus, there's duplicate work
and interoperability. IMO this is language infrastructure that should
be provided by the language implementation.
Many followups to my blogs about adding optional type checking to
Python (given the latest design I'm leaving off the word "static" :-)
said that interfaces were more important than type checking.
Personally, I think they're interconnected: interfaces make much more
sense if you can also declare the argument types of the methods, and
argument type declarations in Python are unthinkable without a way to
spell duck types -- for which interfaces are an excellent approach.
Phillip Eby's Monkey Typing proposal is an interface-free alternative,
but I find it way too complex to be adopted as a standard Python
A few more arguments against ABCs: they seem the antithesis of duck
typing. Using ABCs for type declarations suggests that isinstance()
is used for type checking, and even if reality is not quite that
rigid, this suggestion would be leading people into the wrong
ABCs also allow, nay, encourage, "partially abstract" classes --
classes that have some abstract methods and some concrete ones. Of
course, such a class as a whole is still abstract, but the resulting
mixture of implementation and interface complexifies the semantics.
It has been suggested, especially by Ping, that there is a need to
specify some semantics in interfaces. A typical example involves a
file, where various operations such as readline() and readlines(), can
be implemented by default in terms of a more primitive operation -- in
this case read(). Unfortunately, I believe that this approach is not
very practical, since those default implementations are usually
inefficient, and the choice of the "most primitive" operation is often
dependent on the situation. I also suspect that outside some common
standard types there aren't all that many uses for this pattern. But
if you have to do this, a mix-in class for the "default" functionality
separate from the interface would work just as well as combining the
Specifically because they are not classes, interfaces allow for clear,
distinct semantics. (That is, the semantics of interface objects; I
intend for interfaces to be neutral on the issue of the semantics of
the objects they describe.) For example, (not that I necessarily
propose this, but this is one way that we could decide to go), in a
class claiming to implement a particular method declared in an
interface, it could be flagged as an error if the actual
implementation required more arguments than declared in the interface,
or (assuming we can have type declarations in interfaces as well as in
classes) if the argument types didn't match.
Python has a strong tradition that subclasses may redefine methods
with a different signature, and making that an error goes against the
grain of the language. But the explicit use of an interface changes
things and there is seems appropriate that a class should not be
allowed to violate an interface it claims to implement.
So, while I haven't decided that Python 3.0 will have interfaces (or
type declarations), I'd like to go ahead and hypothesize about such a
future, and look at some of the standard interfaces the language would
provide for various common protocols like sequence, mapping and file.
Let's start with files, because they don't require genericity to fully
specify the interface. Here's my first attempt. Note that I'm
simplifying a few things; I'd like to drop the optional argument to
readline() and readlines(), and I'm dropping the obsolete API
def readline() -> str:
"Returns the next line; returns '' on EOF"
def next() -> str:
"""Returns the next line; raises StopIteration on EOF.
next() has one special property: due to internal buffering,
mixing it with other operations is not guaranteed to work
properly unless seek() is called first.
def __iter__() -> file:
def read(n: int = -1) -> str:
"""Reads n bytes; if n < 0, reads until EOF.
This blocks rather than returning a short read unless EOF is
reached; however not all implementations honor this
(Did you know the default argument was -1?)
def readlines() -> list[str]:
"Returns a list containing the remaining lines"
def seek(pos: int, how: int = 0) -> None:
"""Sets the position for the next read/write.
The 'how' argument should be 0 for positioning relative to
the start of the file, 1 for positioning relative to the
current position, and 2 for positioning relative to the end
of the file.
def tell() -> int:
"Returns the current read/write position"
def write(s: str) -> None:
"Writes a string"
def writelines(s: list[str]) -> None:
"""Writes a list of strings.
Note: this does not add newlines; the strings in the list
are supposed to end in a newline.
def truncate(size: int = ...) -> None:
"""Truncates the file to the given size.
Default is the current position.
def flush() -> None:
"Flushes buffered data to the operating system."
"Closes the file, rendering subsequent use invalid"
def fileno() -> int:
"""Returns the underlying 'Unix file descriptor'.
Not all file implementations may support this, and the
semantics are not always the same.
def isatty() -> bool:
"Returns whether this is an interactive device"
softspace: int # read-write attribute used by 'print'
# The following are read-only and not always supported
mode: str # mode given to open
name: str # file name given to open
encoding: str|None # file encoding
closed: bool # whether the file is closed
newlines: None|str|tuple(str) # observed newline convention
This brings up a number of interesting issues already:
The file interface does not include standard object methods and
attributes such as __repr__() and __class__. But it does
include __iter__() since this is not supported by all objects.
Moreover __iter__() is defined different than the "generic"
definition of __iter__() would be: since we know that a file's
__iter__ method returns the file itself, we know its type. This
is in general the case for standard APIs that are explicitly
part of a specific interface; we'll see this again for
The argument to writelines() and the return value from
readlines() are lists of strings. I really want to be able to
express that in the interface definition. Even in Pascal,
which has such a nice simple type system, you can say this!
I'm using list[str], following the notation I used in an earlier
blog where I was brainstorming about generic types.
Rather than distinguishing between None and its type, for
conciseness I'm using the singleton value as its own type.
While type(None) is not None and never will be, in type
expressions, None stands for type(None).
In a few places, a value may be either a string or None; or
either an int or None. I'm using the notation str|None
respectively int|None for this, which also debuted in an earlier
The argument to truncate() has a dynamic default. I'm proposing
the notation ... for this; I don't want to say -1 because
passing int -1 doesn't have the same effect, unlike for read().
The semantics of this notation are that an implementation may
choose its own default but that it must provide one.
There's the thorny issue of some APIs that aren't always
defined. I'm not going to introduce a notation for this yet;
rather, I'll just say it in a comment. The default type
checking algorithm will accept partial implementations of an
The file interface has a few attributes, one of which
(softspace) is writable. This must be supported or else the
print statement won't work righty when directed to such a file.
For now I'm using the notation:
and indicating the read-write-ness in a comment. The notation
is less than ideal because it doesn't allow to attach a doc
string. I could use this:
name: type "docstring"
but I fear that Python's parser isn't smart enough to always
know where the type expression ends and the docstring begins
(since 'type' can be an expression, syntactically).
Note that softspace is conceptually a bool, but implemented as
an int, and that's how it's declared here.
The return type of close() is problematic. Usually it is None,
but for file objects returned by os.popen() is is an int. I've
chosen to leave out the '-> None' notation on the close()
method, leaving its return type unspecified. I could also have
written '-> int|None'. Or we could have a rule that allows
a method that is declared to return None to return a different
type, perhaps after subclassing.
It would be lovely to be able to declare exceptions, even if we
don't assign any semantics to this (Java checked exceptions have
turned out to be a horrible thing in practice). But I'm leaving
this to a future brainstorm.
What about argument names and keyword parameters? In the above
example, I don't intend to allow keyword parameters on any of
the interfaces. But what if an interface wants to define
keyword parameters? What if you want to require certain
parameters to be given as keyword parameters (and you still want
to declare their types)? Maybe we need a notation to explicitly
say that an argument can or must be a keyword parameter? Or
maybe it would be sufficient to allow leaving out the parameter
name if it is supposed to be always positional? Then the
declaration of read() would become:
def read(:int = -1) -> str: "reads some bytes [...]"
Here's my attempt at defining a generic sequence interface. Note that
I'm declaring this as a generic type, with 'T' being the type
parameter. This despite my earlier promise not to bother with generic
types. I think they are both useful and easy to implement, even if
there are some thorny issues left: a dynamic check for list[int] is
very expensive (it has to check every item in the list for int-ness)
and any mutation of the list might change its type:
def __iter__() -> iterator[T]: "returns self"
def next() -> T: "returns the next item or raises StopIteration"
"""An iterable should preferably implement __iter__().
__getattr__() is a fallback in case __iter__ is not defined.
Note that an iterator is a perfect candidate for an iterable, by
virtue of its __iter__() method.
def __iter__() -> iterator[T]: "returns an iterator"
def __getitem__(i: int) -> T: "returns an item"
def __getitem__(i: int) -> T: "gets an item"
def __setitem__(i: int, x: T) -> None: "sets an item"
def __delitem__(i: int) -> None: "deletes an item"
def __iter__() -> iterator[T]: "returns iterator"
def __reversed__() -> iterator[T]: "returns reverse iterator"
def __len__(): int: "returns number of items"
def __contains__(x: T): bool: "returns whether x in self"
def __getslice__(lo: int, hi: int) -> sequence[T]:
"gets a slice"
def __setslice__(lo: int, hi: int, xs: iterable[T]) -> None:
"sets a slice"
def __getitem__(x: slice) -> sequence[T]:
"gets an extended slice"
def __setitem(x: slice, xs: iterable[T]) -> None:
"sets an extended slice"
def __delitem__(x: slice) -> None:
"deletes an extended slice"
def __add__(x: iterable[T]) -> sequence[T]:
def __radd__(x: iterable[T]) -> sequence[T]:
"right-handed concatenation (+)"
def __iadd__(x: iterable[T]) -> sequence[T]:
"in-place concatenation (+=)"
def __mul__(n: int) -> sequence[T]: "repetition (*)"
def __rmul__(n: int) -> sequence[T]: "repetition (*)"
def __imul__(n: int) -> sequence[T]: "in-place repetition (*=)"
# The rest are all list methods -- should we really define these?
def append(x: T) -> None: "appends an item"
def insert(i: int, x: T) -> None: "inserts an item"
def extend(xs: iterable[T]) -> None: "appends several items"
def pop(i: int = -1) -> T: "removes and return an item"
def remove(x: T) -> None:
"removes an item by value; may raise ValueError"
def index(x: T) -> int:
"returns first index where item is found; may raise ValueError"
def count(x: T) -> int: "returns number of occurrences"
def reverse() -> None: "in-place reversal"
# But not sort() -- that's really only a list method
Some additional issues with this:
The syntax for declaring a generic interface (interface X[T])
requires a bit of a leap of faith. But without parameterization
we can say so much less about a sequence than what is common
knowledge (and what a type inferencer should know) that I find
it nearly useless to bother defining a sequence type without
this notation. Possibly an implementation that ignores the type
parameter T would be acceptable; use of T would be purely for
the benefit of the human reader.
I had to introduce two auxiliary interfaces:
iterator, something with primarily a next() method
iterable: something with primarily an __iter__() method,
although something implementing __getitem__() will also work.
That makes its declaration a bit awkward (with both methods
being optional but at least one being required).
I struggled a bit with the two possible signatures for
__getitem__ and friends: it is normally called with an int
argument, returning a single item, but the extended slice
notation (e.g. seq[1:2:3]) calls it with an argument that is a
slice object, and then it returns a sequence. Declaring the
argument and return types as unions feels unsatisfactory because
it throws away information. I decided to use the @overloaded
decorator, which can be implemented using a small amount of
Should we have separate interfaces for immutable and mutable
sequences? For now I'd rather only have one; the notion that an
implementation may leave out methods naturally allows for
Should the sequence interface mention virtually everything that
a list can do, or should it be minimal?
Even if the sequence interface is inclusive (containing most
list methods), I'd like to leave sort() out of it; sort() is
really unique to the list type, and even if some user type
defines a sort() method, it's unlikely to have the same
signature as list.sort() (especially after what we did to this
signature in Python 2.4). Feel free to prove me wrong.
In current Python, the + operator on standard sequence types
only accepts a right operand of the same type (list, tuple or
str). But the += operator on a list accepts any iterable! I
think + on any two sequences, or even a sequence and an
iterable, in either order, should be allowed, and should return
a new sequence. However, iterable + iterable should be left
undefined; this is because iterator + iterator is not defined,
and I think it should not be.
I stay sceptical about "optional static typing" ( or however you rename it ) and interfaces in Python because I'm not sure how this stuff fits with Pythons dynamicity? Static types are assurances about the types of the values created in a program that can be checked without executing the program. If a type system is not broken and if it is implemented appropriately type safety can be assured. I don't see anything of this happening to Python with your inventions. If you continue to allow adding and removing object attributes at runtime you can never be sure that an object conforms to an interface except you make a complete check whenever a method expects an object with a certain interface. In the end I'm confused about what is reliable meta-information about my program and what is not?
By the way I don't understand "duck-typing". It seems to be a funny way to talk about Leibniz identity of indiscernibles pronouncing the behavioural aspect of some object. But no method signature can answer the question how some thing behaves. An interface can at best guarantee method calls and attribute access ( but not even that in Python ). So what is meant by a type in duck-typing?
> # The following are read-only and not always supported
I don't think it's a good idea to include some attributes in an interface that are not always supported. This is exactly what I want to avoid when using an interface, I want a guarantee that all the interface requirements are met.
If there are some attributes that are OS dependant or will not be available on some file-like objects (like sockets), I think what attributes shouldn't be part of the Interface, or may to have 2 interfaces, like:
"The only argument that comes to mind is that ABCs don't require more syntax. That's usually a strong argument in Python. But it seems that at least two of the largest 3rd party projects in Python (Zope and Twisted) have already decided that they can't live without interfaces, and have created their own implementation. From this I conclude that there's a real need."
Just because they "can't live without interfaces" doesn't really mean that there is a real need. I think interfaces and static typing are entirely against the spirit and power of Python. If those people want to use interfaces, then let them get together and create a third-party package for interfaces that they both agree upon and leave it third party.
I agree with one of the above posters that interfaces just don't lend themselves to a dynamic language like Python. In the end, they provide little usefulness apart from documentation. If you really want to achieve the effect of interfaces, build in something better than docstrings and more like Javadoc that will allow the user to document their code and generate really great documentation, along with information about what methods expect as parameters, and what they return.
In the end, I much prefer thinking in terms of "file-like objects" rather than in terms of "implements IFile".
> I agree with one of the above posters that interfaces just > don't lend themselves to a dynamic language like Python.
I'll grant you that in the small, they might not provide much value, but when you start talking about adaptation, making security declarations about objects, or interfacing with large/complex libraries, interfaces make much more sense. Luckally we can have both, as interface checking will be optional.
It is only recently in my career that I have started using languages that support interfaces. I went from mainly using Python to mainly using C# about 3 years ago.
I find interfaces in C# to be usefull, but they would be far more usefull if one could define default methods on the interface (which would have no access to instance state), and if the interface defention allowed pre/post-conditions to be specified as part of the contract.
Without pre/post-conditions being specified, an interface adds little value beyond matching the names of methods and the types of their arguments.
Interfaces. Ugh. Smells like Java. And why does Java have interfaces? Because it doesn't allow multiple inheritance. And why doesn't it allow multiple inheritance? The fear that the programmer will shoot his foot off with it. And why Java's dire need for inheritance/interface? Compile-time type checking.
Python doesn't have compile-time type checking and has already put a lot of thought into MRO and the diamond problem. Why not encourage multiple inheritance of ABCs?
Perhaps developers are accustomed to envisioning a Java-like implementation when envisioning large projects. The only true benefit I can see to interfaces (and static-like types) is how much easier it might be to create a powerful IDE for Python developers. Or perhaps, how much easier it might be to adapt an existing IDE to do cool things with Python code. The better the IDE, the easier the large project.
What the "str" here should be? Is it the type "str" or any object providing the "str" interface, defined somewhere else?
In the standard library there are many methods that require a "file-like" object (one example is ftplib). Defined as part of some interface, what will they require, a type "file" or an object of any type that provides the "file" interface?
With interfaces defined in terms of ABC, we have no such a problem - the interface is a class.
> Interfaces. Ugh. Smells like Java. And why does Java have > interfaces? Because it doesn't allow multiple inheritance. > And why doesn't it allow multiple inheritance? The fear > that the programmer will shoot his foot off with it. And > why Java's dire need for inheritance/interface? > Compile-time type checking.
While these points might be some of the motivation, there are many benefits to having interfaces. One of the primary benefits is in the use of RMI for remote access to services. Having an interface means that a small amount of code is shared by all to document how the systems work together. The implementation comes to the user via mobile code, and this, makes it possible to adapt and extend implementations independently of the interface definition.
J2EE and a lot of other containers encourage you to put everything in the JVM and utilize interfaces such as SQL, XML etc. to exchange information. Both SQL and XML are interfaces by definition. There is a specific template of syntax/semantics that you have to use to talk to the remote system.
It's not an interface that is part of the programming language syntax and type system (not yet anyway), but it is an interface.
So, interfaces have been proven to be very important to separating implementation from contract/description. Java's interfaces empower the developer to do a lot of things with more visible documentation of the specifics of the system.
Poorly defined interfaces are those that are so generic that you can't possibly guess what might happen. Better defined interfaces have narrow enough argument lists that it is clear what will happen just by eyeballing the javadocs.
Clearly a wide range of good vs bad interface design has occcured in lots of places. Proper architectures come from experience and training, not from language features. Language features enable the developer/architect/programmer to be more effective at expressing and designing the structure of the software that is the architecture!
> ... there > are many benefits to having interfaces. One of the > primary benefits is in the use of RMI for remote access to > services. Having an interface means that a small amount > of code is shared by all to document how the systems work > together. The implementation comes to the user via mobile > code, and this, makes it possible to adapt and extend > implementations independently of the interface > definition.
So, you are saying that beyond documentation, interfaces are good for "documenting how the systems work together"? Wow, way to take an entire paragraph to restate and prove my point! Interfaces are good for very few things:
1. Documenting how things work. This can be achieved just as well without the use of interfaces. 2. Static type checking. This is just about as far from Pythonic as I can think of, and can already be done via metaclasses, decorators, and any number of other methods. In addition, type checking is automatically slower than not type checking, since it will have to occur at runtime. 3. "Adaptation" systems, but this is just one way to do it. Technically, you don't need an interface at all for adaptation, just a string that describes that interface. I have written systems like this before, and its silly to state that interfaces are the _only_ way to do it.
The only other argument I have heard is that they are useful in "large systems" but aren't necessary in "small systems" as someone said above. I don't buy this argument either, as I have been writing large systems in Python for a long long time, and I have never needed interfaces, just good documentation.
> J2EE and a lot of other containers encourage you to put > everything in the JVM and utilize interfaces such as SQL, > XML etc. to exchange information. Both SQL and XML are > interfaces by definition. There is a specific template of > syntax/semantics that you have to use to talk to the > remote system. > > It's not an interface that is part of the programming > language syntax and type system (not yet anyway), but it > is an interface.
Your point is that SQL and XML are in some way interfaces of some kind. Sure, they are. But your point brings to mind an excellent example of the differences between the Pythonic "protocols" way of doing things versus the Java/C# "interfaces" way of doing things: two very popular ways to write web services (REST and SOAP).
SOAP is created by Java/C#/XML/strongly-typed people and has giant WSDL descriptor files to state how services work, XML schemas to type and define each and every interaction, and tons of validation, type checking, and static definition for things. REST takes a different approach, relying more on the developer to write good documentation. SOAP is popular amongst C#/Java people, but is really looked down upon by dynamic language people (Python, Ruby, etc) because its overly complex. REST is easier to implement, works better, and is inherently faster!
To me, adding interfaces to Python would go against everything that Python is about. Come up with something else to do the same thing in a more Pythonic way, and maybe I could be convinced. Right now its just complexity for the sake of complexity. If you really feel some need in your heart for interfaces in your language, then you also want static typing, and you should just use Java or C#. You would feel more comfortable there.
> So, interfaces have been proven to be very important to > separating implementation from contract/description. > Java's interfaces empower the developer to do a lot of > f things with more visible documentation of the specifics > of the system.
I have worked with very large Java systems that have been created upon Interfaces as the core method of integrating with frameworks, and I always found it to be overly complicated and difficult to use. Java libraries often work this way, and using them often requires me to implement a bunch of interfaces that I may not even like the design of. In python, libraries usually have a few simple module-level methods or a few useful classes that allow me to get things done without having to go out of my way to reimplement my classes, or inherit anything.
> Poorly defined interfaces are those that are so generic > that you can't possibly guess what might happen. Better > defined interfaces have narrow enough argument lists that > it is clear what will happen just by eyeballing the > javadocs.
Most interfaces are poorly defined. Adding this to the language would introduce a ton of poorly defined interfaces to the Python world, and I don't think thats something I am really excited about.
> Clearly a wide range of good vs bad interface design has > occcured in lots of places. Proper architectures come > from experience and training, not from language features. > Language features enable the > e developer/architect/programmer to be more effective at > expressing and designing the structure of the software > that is the architecture!
But people who seem to want interfaces in Python (2 projects out of the entire Python world... *TWO*) have implemented one that they can live with. Thats great, let them use their own modules for doing this thing that they think is important. But don't put it in the language.
> I find interfaces in C# to be usefull, but they would be > far more usefull if one could define default methods on > the interface (which would have no access to instance > state), and if the interface defention allowed > pre/post-conditions to be specified as part of the > contract.
I agree with the people who are sceptical about whether the whole interfaces concept fits with the dynamic spirit of Python.
Interfaces intend to nail down a set of method signatures that apply to objects of classes implementing those interfaces. However, I think there are already easy and powerful ways of asserting this, and more.
A unit test can define not just the signature, but also semantics of objects. This can include any condition expressable in Python, including things like pre-/post- conditions and invariants. As I see it, this provides all the power of interfaces, without needing any additional language magic.
Zope and Twisted are the two most un-pythonic high-profile projects that happen to be written in python that I can think of. "Zope and Twisted (think they) need it" is a lousy reason to add a feature that will be horribly mis-used by the Java don't-get-zen-of-python-yet newcomers for years to come, particularly when said projects already have their own solution.
I have a lot of strong feelings about this issue, so I don't want to see the whole thing go sour in the face of people who keep misunderstanding the basic concepts. Guido, you never should have called this static typing in any way! People would have still gotten the ideas confused, but not nearly so many.
To Everyone who thinks Interfaces must mean Static Typing: This is simply false. Interfaces in Python are more of an adaptation (pun!) of the interfaces in other languages, like Java and Obj-C, than the original ideas themselves. Python's duck typing is about as dynamic a typing system as you can get. So much so that it is really more of a lack of a typing system than anything else.
A lot of people are commenting, both here and elsewhere, that interfaces are little more than documentation. Perhaps, but if this is true, then you must look at the form of the documentation: it is machine readable, unlike human language. It is documentation to the runtime (they are dynamic, not static) that allows a more reliable way to identify what an object is capable of. Most importantly is the adaptation this allows, as the adaptation registry needs to know what all the objects can do, to make them do what you want them to do.
Now, on to my comments about Guido's post itself.
I really dislike the list[str] expression, because it leaves a gap when dealing with user-defined interfaces and types? If I have a type defined that is some container, and I then do foo[bar], how will Python know if I mean "foo with elements conforming to bar" or "the interface found in mapping foo by key bar"? This ambiguity is not a good idea. I propose instead that types must be valid expressions as in any other part of a Python script, with no special meanings. We can do things like listOf(str) to create an interface that is the list interface, but where all elements are of the str type. There is also some confusion on my end as to why you did list[str] and tuple(str). Was that a mistake? Finally, on this topic, I note that the | operator on types here is also breaking of normal expression semantics, and either the pipe operator used on types should return something as the listOf placeholder interface I mentioned, but matching any one of a choice of interfaces, or a callable be defined to pass a list of types to, also to gain such an object.
I'm also disliking the sequence[T] syntax. At least as it stands, it is too strange. I understand the meaning and reasoning behind it, but I propose another route. Why not get rid of the T stuff there, and instead define a second interface, which would inherit sequence. Call it typedsequence. This would define a new attribute elemtype, and define in the right places that certain arguments and return values must conform to elemtype. Now, how we refer to the attribute on an instance conforming to the element, from within the interface definition, I am not sure. There is no self argument to refer to, so perhaps this issues requires further thought.
Now, you define two extra interfaces here for the sequence, but I think you aren't taking it far enough. We need more fine-grained interfaces. We need to be able to say "this object contains other objects, and keeps them in an ordered sequence", while omitting a specification the elements are all unique (sets), or that they are referred to by unique keys (dictionaries). We can break these behaviors down to their most basic ideals, and mix and match to get the exact behavior we need, no less and hopefully no more, but more is OK if that's whats available. But the basic thought here is to be able to specific better the exact minimum that you want supported by the object.
And, one last note, in reguards to the "iterator + iterator" business. What if it were defined as returning an iterator, which would iterator just like the left iterator until StopIteration, and then use the right iterator. The implementation should handle both iterators and iterables.
> > ... there > > are many benefits to having interfaces. One of the > > primary benefits is in the use of RMI for remote access > to > > services. Having an interface means that a small > amount > > of code is shared by all to document how the systems > work > > together. The implementation comes to the user via > mobile > > code, and this, makes it possible to adapt and extend > > implementations independently of the interface > > definition. > > So, you are saying that beyond documentation, interfaces > are good for "documenting how the systems work together"? > Wow, way to take an entire paragraph to restate and prove > e my point! Interfaces are good for very few things:
Yes, but it is machine readable documentation that is a nice formal contract that can be verified absolutely.
Runtime typing and duck typing are flexible. But, they can also lead to a lot of extra work in test development, to do things that a static typing compiler already provides the ability to do. The static typing compiler gets written once so everyone can use its built in testing facilities.
An interface is a compile time test!
Flat View: This topic has 42 replies
on 3 pages