Why don't we require interfaces in dynamic languages?

Question

Is it just because of dynamic typing we don't require a concept of interfaces(like in Java and C#) in python?

Semipermeable

Yes. (filling the remaining space to reach 15 chars) – Infantry

I asked a related question before. #2351468 – Broyles

How do you know what we require? – Coactive

Also, note the importance of duck typing - I don't care if you are a Squid or a Car - if you can .honk(), you are acceptable. Note Python's whole "let's emulate a file()" pattern for a good example of why interfaces don't exist. – Ricard

Answer 1

The interface as a keyword and artifact was introduced by Java¹ ( and C# took it from there ) to describe what the contract an object must adhere was.

But, interface has always been a key part of Object Oriented Paradigm and basically it represents the methods an object has to respond. Java just enforces this mechanism to provide statically type checking.

So, dynamic ( OO ) programming languages do use interfaces, even thought they don't statically check them. Just like other data types, for instance in Ruby:

 @i = 1;

You don't have to declare i of type FixNum you just use it. Same goes for interfaces, they just flow. The trade-off is, you can't have a static check on that and failures are only show at runtime.

In the other hand Structural type ( or static duck type as I call it :P ) used by languages as Go or Scala, gives the best of both worlds.

_{1. See Daniel Earwicker comment about CORBA interface keyword}

Ssm

I'd add an additional +1 for mentioning Structural typing, if I could. It's a great concept. – Imalda

Another +1 for structural typing – Pinup

"The interface as a keyword and artifact was introduced by Java". Not really sure about that. CORBA's IDL (1991) has the interface keyword, and in C++ release 2.0 (1989) a class with all pure virtual member functions is semantically identical to an interface. So I'd guess that perhaps Java borrowed the keyword from CORBA in order to give special prominence to the language feature idea borrowed from C++. – Boxer

And another +1 for static structural typing though again I have to point to C++ (templates) as the most widespread example. – Boxer

Answer 2

We don't require them, but we do support them. Check out Zope Interfaces (which can be and are used outside of Zope).

Bosporus

Answer 3

It's worth noting that, contrary to what many people will say as a first response, interfaces can be used to do more than document "what methods a class supports". Grzenio touches on this with his wording on "implement the same behaviour". As a specific example of this, look at the Java interface Serializable. It doesn't implement any methods; rather it's used as a "marker" to indicate that the class can be serialized safely.

When considered this way, it could be reasonable to have a dynamic language that uses interfaces. That being said, something akin to annotations might be a more reasonable approach.

Imalda

For how clumsy it could look like, here is one case where a language like PHP shines. – Pliner

Answer 4

Interfaces are used in statically typed languages to describe that two otherwise independent objects "implement the same behaviour". In dynamically typed languages one implicitly assumes that when two objects have a method with the same name/params it does the same thing, so interfaces are of no use.

Dull

Answer 5

Interface constructs are used in statically typed languages to teach the type system which objects are substitutable for each other in a particular method-calling context. If two objects implement the same method but aren't related through inheritance from a common base class or implementation of a common interface, the type system will raise an error at compile time if you substitute one for the other.

Dynamic languages use "duck typing", which means the method is simply looked up at runtime and if it exists with the right signature, it's used; otherwise a runtime error results. If two objects both "quack like a duck" by implementing the same method, they are substitutable. Thus, there's no explicit need for the language to relate them via base class or interface.

That being said, interfaces as a concept are still very important in the dynamic world, but they're often just defined in documentation and not enforced by the language. Occasionally, I see programmers actually make a base class that sketches out the interface for this purpose as well; this helps formalize the documentation, and is of particular use if part of the interface can be implemented in terms of the rest of the interface.

Dilly

Answer 6

One key thing about at least some dynamic languages that makes explicit interfaces more than a little awkward is that dynamic languages can often respond to messages (err, “method calls”) that they don't know about beforehand, even doing things like creating methods on the fly. The only real way to know whether an object will respond to a message correctly is by sending it the message. That's OK, because dynamic languages consider it better to be able to support that sort of thing rather than static type checking; an object is considered to be usable in a particular protocol because it is “known” to be able to participate in that protocol (e.g., by virtue of being given by another message).

Divvy

And by “given by another message” I mean passed as an argument to a method call, or returned from a method call. – Divvy

Answer 7

Perl has Roles (or traits ), It is more than interfaces unlike java perl roles we can have a implementation check out these links for more on perl roles

• http://en.wikipedia.org/wiki/Perl_6#Roles
• http://use.perl.org/~Ovid/journal/38649

Ninefold

Answer 8

In C# and Java, interfaces are just abstract classes with all abstract methods. They exist to allow pseudo multiple-inheritance without actually supporting full-blown multiple inheritance and the ambiguity multiple inheritance creates.

Python supports multiple inheritance and has its own way of determining which parent's method should be called when a method exists in multiple parents.

Romanov

"In C# and Java, interfaces are just abstract classes with all abstract methods." Ah, if only that were true! smellegantcode.wordpress.com/2008/05/22/virtual-properties-in-c – Boxer

Answer 9

Dynamic languages are Duck Typed

If it walks like a duck and quacks like a duck, it must be a duck

http://en.wikipedia.org/wiki/Duck_typing

In other words, If you exect an object to suport the Delete() method, than you can just use the

obj.Delete()

method but if the object doesn't support Delete() you get a Runtime error. Statically typed languages wouldn't allow that and throw a compile time error. So you basically trade type safty against faster developement time and flexibility.

Without interfaces you can do something like that in static languages:

void Save(MyBaseClass item)
{
    if (item.HasChanges)
        item.Save()
}

but that would require every object that you pass to this method to inherit from MyBaseClass. Since Java or C# don't support muliinheritance that isn't very flexible because if your class already inherits another class it cannot inherit from MyBaseClass, too. So the better choise would be to create a ISavable interface and accept that as a input parameter to ensure that item can be saved. Then you have best of both: type safety and flexibility.

public interface ISavable
{
    bool HasChanges {get;set;}
    void Save();
}

void Save(ISavable item)
{
    if (item.HasChanges)
        item.Save()
}

The last backdoor is to use object as a parameter if you cannot expect every item that will use your save method to implement the interface.

void Save(object item)
{
    if (item.HasChanges)
        item.Save()
}

But than again, you don't have compile time checking and probably get a runtime error if someone uses your method with an incompatible class.

Exhibitionism

"Dynamic languages are Duck Typed". That's a pretty wild thing to say. It needn't be entirely true. – Thornberry