[5.0] Backwards Compatible Interfaces

[anlutro]

A lot of interfaces that existed in 4.2 have been renamed/moved namespace. This is already breaking some of my packages. Some of the damage can be mitigated by keeping the old interfaces but letting them extend the old ones. For example:

<?php namespace Illuminate\Support\Contracts;
interface ArrayableInterface extends \Illuminate\Contracts\Support\ArrayableInterface {}

However, even using this solution, core Laravel code that checks type-hinting against the new (moved) interfaces won't work with old packages (Illuminate\Support\Contracts\ArrayableInterface is an instance of Illuminate\Contracts\Support\ArrayableInterface but not the other way around), so there's likely going to be a slew of packages that work pre-4.3 that will break.

This is especially annoying as you can't conditionally extend one interface or another depending on which version of Laravel the package user has installed.

[JoostK]

There is a solution, by using class_alias to refer the old names to the new ones. This can either be done by Laravel or a package can do it manually before any of its files are loaded.

There may also be the need for a 'legacy' package that defines all those aliases, so any package wanting to support both < 4.3 and >= 4.3 can composer-require it to avoid having to contain the aliasing code in every single package (because I doubt this is going to end up in core)

[jasonlewis]

I agree. Although I'm fairly sure what I'm working on doesn't directly use
any of the interfaces it would be unwise to proceed without providing some
legacy support, Illuminate\Legacy perhaps.
On 25 Aug 2014 23:50, "Joost Koehoorn" notifications@github.com wrote:

There is a solution, by using class_alias to refer the old names to the
new ones. This can either be done by Laravel or a package can do it
manually before any of its files are loaded.

There may also be the need for a 'legacy' package that defines all those
aliases, so any package wanting to support both < 4.3 and >= 4.3 can
include it to avoid having to include it in every single package (because I
doubt this is going to end up in core)

—
Reply to this email directly or view it on GitHub
#5551 (comment).

[anlutro]

Completely forgot about class_alias. It does indeed work, though I feel bad for doing it. One thing I wasn't aware of is the PHP function interface_exists which you have to use instead of class_exists.

It would be possible to put a class_alias call in the old namespace location to make it work fully with autoloading, but this would obviously clutter up the project with a lot of duplicate files. These clutter files could be added to a legacy package as mentioned.

The alternative is a package/file/function that does all the if (interface_exists(...)) checks and adds the appropriate aliases, but this does trigger a lot of unnecessary autoloading.

And I still think this is far from ideal, as it requires every package maintainer to update their package to make it work with both pre- and post-4.3. Maybe laravel/framework could require the legacy package in 4.3 but it is removed in the following minor version, giving people time to move to the new namespaces?

[GrahamCampbell]

I'm kind of against this. Also, the next version is 5.0, so breakages should be ok. Maybe bc aliases could be provided in a third party package?

[anlutro]

Issue was opened when version was 4.3.