Helpers potentially cause issues outside of Laravel

[danharper]

I'm not sure how much of a priority you're making the portability of the Illuminate components outside of a Laravel app, but I thought I'd raise this issue anyway.

I'm attempting to use the Database package (via Dan Horrigans's Capsule) in a FuelPHP app (with the aim to slowly port to Laravel 4). However the helpers.php file from Illuminate\Support causes conflicts where functions have previously been defined (namely e()).

Perhaps these helpers could become methods of a separate package which Laravel depends on. And a new set of helpers inside Laravel could simply becoming aliases to the package's methods?

(For now I've worked around this issue in a very hacky way)

[Anahkiasen]

Yup, having a lot of problems with this too, maybe the helpers could be loaded optionally, or only inside of Laravel ? This mainly causes a problem for me when I want to use a Laravel 4 package ported to Laravel 3 – as all packages use illuminate/support you can't use Composer's autoloader as it loads the helpers file and it conflicts with Laravel 3's.

[franzliedke]

Loading them optionally (or making it possible to deactivate loading easily) sounds like a good idea.

On Thu, Mar 7, 2013 at 4:20 PM, Maxime Fabre notifications@github.comwrote:

Yup, having a lot of problems with this too, maybe the helpers could be loaded optionally, or only inside of Laravel ?

— Reply to this email directly or view it on GitHubhttps://github.com/laravel/framework/issues/527#issuecomment-14566073 .

[billmn]

Is also possible define the helper only if the function doesn't exists But what about the parts of Laravel code that use this helpers?

if ( ! function_exists('helper_name'))
{
   ....
}

[bencorlett]

@billmn has hit the nail on the head.

[bencorlett]

I think #530 will most likely fix your issues, however I can see one issue. Because the helpers.php file is being required using composer, it will load first.

The only true way to get around it that I can see, is to have an illuminate/functions package which itself relies on illuminate/support. But the thing is, most of the packages (at least that I have written which require support) use the string / array functions, which brings us back to our original problem.

I think for the most part we are safe keeping it there, it's just very (possible) generic functions like e() are going to cause headaches for some people.

IDK lol.

[danharper]

A lot of the helper methods are simply aliases of methods in an existing support class. I propose the remainder are made like that.

helpers.php can then either be a new micro package with support as a dependency; or part of laravel/framework, but some people may want to use them separately.

All the Illuminate packages would have to not use the helper functions, and instead use the methods provided by support. The result is slightly more verbose code in places, but it brings the ability to use Illuminate components outside of Laravel without conflicts.

Sound right?

[taylorotwell]

Merged a pull from @bencorlett which should alleviate some of this. #530