What's the difference between a Contract in Laravel and an Interface in PHP?

Question

As far as I can tell, Laravel refers to the interfaces it extends as Contracts because they are used by Laravel. But this seems a bit like circular reasoning. There is no value added in changing the terminology of an existing PHP feature simply because your project uses it.

Is there something more to it? What's the logic behind coining a new term for something that's a standard PHP feature? Or is there some feature of Contracts that are not already in Interfaces?

Edit: To clarify, it's the usage of Contract as a proper noun in the documentation that has me confused, as explained in my comment on Thomas's post

Answer 1

"Contract" isn't some new terminology that Taylor coined. It's a very common term programmers use.

An interface is a contract, but a contract doesn't necessarily have to be an interface. The interface in a nutshell defines the contract that the classes must implement.

An abstract class is also a contract. The difference is that an abstract class can provide actual implementations, state, etc., and as a result, it is (in a sense) a more rigorous contract.

Another key difference is that a child class can only extend 1 abstract class but it can implement multiple interfaces.

So basically, "contract" isn't a new naming convention. It's a common term that Taylor is using.

Answer 2

It's just a nice word to describe the idea of using interfaces.

Laravel contracts are just PHP interfaces so they don't provide any other functionality.

You can read more on this subject in the documentation http://laravel.com/docs/5.1/contracts