Obviously, there are a few minor todos as you mentioned, but this accomplishes all of the goals of my other PR's that you listed, but indeed, in a much simpler way (and a smaller code footprint). I'm very pleased by this version!

The updated routing method looks good to me. 👍 in general - except for the name of course :)

@fabpot if we want some tests (there's not much to test, but there could be some) or other changes and I can help - let me know and I can steal this PR and make those changes (and take all the credit!)

Here is a small usage example:

<?phprequire_once__DIR__.'/../vendor/autoload.php';useSymfony\Component\Config\Loader\LoaderInterface;useSymfony\Component\Debug\Debug;useSymfony\Component\DependencyInjection\ContainerBuilder;useSymfony\Component\HttpFoundation\Request;useSymfony\Component\HttpFoundation\Response;useSymfony\Component\HttpKernel\MicroKernel;useSymfony\Component\Routing\RouteCollectionBuilder;class AppKernelextends MicroKernel{publicfunctionhome()    {returnnewResponse('Foo');    }publicfunctionregisterBundles()    {returnarray(newSymfony\Bundle\FrameworkBundle\FrameworkBundle(),        );    }protectedfunctionconfigureRoutes(RouteCollectionBuilder$routes)    {$routes->add('/','kernel:home');    }protectedfunctionconfigureServices(ContainerBuilder$c,LoaderInterface$loader)    {$c->setParameter('kernel.secret','foo');    }}$kernel =newAppKernel('dev',true);$request = Request::createFromGlobals();$response =$kernel->handle($request);$response->send();$kernel->terminate($request,$response);

I'm not quite satisfied as we cannot use a closure for controllers (as Symfony dumps the routes as a PHP file).

Question: is it really something we want to package in Symfony itself. As you can see, the code is quite minimal, so isn't it something for asmall/micro distribution? Or part of a tutorial in the docs? For me, that's more like a starting point rather than some kind of infrastructure that needs to be standardized.

If this is something that will be asked for frequently, I would say yes (personally I don't see any use cases for myself right now). The code that would reside inside the core looks good so far.

The fact that closures cannot be used defeats the initial purpose (at least for me). With closure support, that would make it something interesting for small websites, APIs, things that Silex is good at.

@fabpot I want the codesomewhere where people can just use it, so people can get a minimal Symfony project up and running really quickly and with minimal setup. If we make the user do that boilerplate, it defeats the purpose.

My vote is for core because I want say: "you can create a symfony app by requiringsymfony/symfony and creating a single file that extends MicroKernel" (or whatever we call it).

Also, I think the kernel should be used in the SE: I think loads things in a way that's more clear, but basically works the same (you could easily removerouting_dev.yml for example).

And finally, yes, Silex is awesome. But it doesn't have bundle support, which means I forfeit a lot of solutions I might be accustomed to using. A Silex app also can't evolve into a full Symfony app very easily if it grows. The idea behind this was - as much as possible - to have my cake and eat it too: get full Symfony, but get it small.

Anyways, I see your point - after all, this class is quite small - but that's my vote. We could move it intoFrameworkBundle if we want to hide it a bit from the core components (especially since it requiresFrameworkBundle.

Also, I don't envision that you'll normally havejust one file, though that ability is cool. More that it's easy to create a minimal application easily: a kernel, controller classes, services and some configuration files if you choose.

I don't like the idea of using this in the Standard Edition. The Standard Edition should be the base template for common Symfony applications, which tend to be quite advanced. This still is a nice feature, but for 20% or so of the Symfony developers.

What about creating a new package, likesymfony/micro, which requiressymfony/symfony and this class. Then you can say"Require thesymfony/micro package, use theMicroKernel class and you're ready".

@weaverryan assume i have several routing files i want added, if both have the same prefix i assume the latter will override the former?

@henrikbjorn it uses the same mechanism as normal route importing. So if you import 5 routes fromadmin.yml and 5 routes fromadmin2.yml - both with the prefix/admin, and you will end up with 10 routes. The only time later routes would override earlier routes is if they have the same route name - the prefix won't matter with that.

Maybe we should allow mounting without a prefix?

Before I answer that, what is theproblem with the current implementation? :) I have some small things that I don't think are necessarily perfect, but I only want to change things if people like@henrikbjorn say "Hey, I was confused by X, it would have been more clear if I could just call Y".

Let's describe what I think (as a non-native english speaker) the discussed function names mean:

• mount() bind 2 things (first and second argument) together
• import() includes something into the current stack

It turns outmount() doesn't mount argument 1 and 2, it mounts argument 2 in the current route collection with an optional prefix defined by 1. If I didn't knew the Yaml syntax behind this (a resource with a prefix option), I would actually think that I cannot bind 2 different route collections to the same mountpoint.

Furthermore, it turns outimport actually doesn't do anything more than loading and returning what it just loaded. The thing you loaded now has to be attached/mounted to the main route collection.

Aboutmount(), it's exactly as it is in Silex (http://silex.sensiolabs.org/doc/organizing_controllers.html). So if it hasn't been a problem there for people, we can assume it won't be a problem here (if it has been a problem, we should't repeat it).

Aboutimport(), I share your concerns. However, if you automatically put the new routes into theRouteCollectionBuilder, then you're not able to modify then further - e.g. add defaults or requirements to the routes injust that collection. Again, this idea comes from Silex (http://silex.sensiolabs.org/doc/providers.html#controller-providers), though it's a bit more obvious there, because you create new class, so it's obvious that it's not being imported until you actually add it to your app. Is it as simple as callingimport() something else? Or makingimport() actuallyimport and adding a less-used method that returns the newRouteCollectionBuilder without mounting it?

We can rename it toload() or import the route collection and return the imported route collection, allowing to change the instance. (this is done with registering Container definitions for instance)

@wouterj you're right - I didn't think about that - that's great :). See#16477.

@weaverryan i think the confusing part for me was the$prefix in mount is the first argument, and i would the assume it would be mandatory and therefor override my ealier prefix. But if the argument order was different egmount($routes, $prefix = null) then i would make sense.

But that would proberly be a bigger BC break than your proposed solution.

Also a lot of the Bundles seems they are geared very much at usage in a directory structure that is the same as the standard edition which is a shame (eg app/Resources/views)

edit: my playground thingyhttps://github.com/henrikbjorn/Muse

All I see is references to 2.8. Just verifying that this will this be in 3.0 too?

It will be merged in the next "merge 2.8 on 3.0" I guess :)

@fabpot I see this was merged in2.8 branch. But 2.8 requiresPHP 5.3.9, while traits are only available inPHP 5.4+ .

Are you sure it's correct to have this in2.8 ?

@SoboLAN this is an additional feature. Symfony doesn't require you to use this feature, so the minimum requirement is still 5.3.9.

If you want to use this feature, you have to use PHP 5.4.

@wouterj You could say that about most of the functionality provided by Symfony.

If a minimum PHP version is specified, then I expect thatabsolutely everything will run without problems if I use Symfony on that PHP version (or newer). That's the whole point of why Composer allows specifying something like this.

I think it's a very reasonable assumption. Why ? Because everyone who has some restrictions on production systems (and most everyone has) and needs to decide what Symfony version to use, will rely on that 1 line incomposer.json (which specifies minimum PHP version) to make his decision. It is the single most important factor in these kind of decisions.

Not respecting that is kind ofalarming for me because I can never know what to expect. I would constantly ask myself:

If I use this method in my project, will it work in production servers ? (where I have a locked and usually older PHP version than on my dev machine)

If you (the deciders of Symfony) strongly believe that it should be like this, then fine. Either way I have no authority to dictate anything around here. But think about it: if you do this now, thenwhere do you draw the line ? If you go down this path, where do you stop ?

I think that it's a dangerous precedent because it takes away all the confidence in thatrequires PHP version X statement.

Without that confidence, what is a developer or devops going to do ? What if he has a big Symfony project (or 20 projects) in his production systems ?Test absolutely every functionality when he makes aroutine patch update (e.g. 2.6.9 -> 2.6.10) ? Just to be sure that what is written incomposer.json is nota lie and that his website won't blow up ?

There are many packages in thesuggest sections of Symfony's framework, components and bundles. These are all libraries that have some kind of integration in the component/bundle, but aren't required for the main usage (for instance,doctrine/annotations is required when using annotations with the Validator component, but as you can use Yaml/Xml/PHP, it's in thesuggest section).

Also, 95% of the people that are going to use Symfony are not going to use this trait. It's a really nice feature, but more to advocate Symfony ("Symfony isn't that massive huge framework you think it is!") and for some people that are not going to base on top of the Standard Edition (and most people installing 2.8 will stick with the Standard Edition).

At last, it's very clear (or debuggable within 30 seconds) that this feature requires PHP 5.4 as you need to use the trait yourself. A developer using this feature on a PHP 5.3 server will either know the trait feature and identifies it as something that requires PHP 5.4 or will get an error message, search for "php trait" on google and find out that it requries PHP 5.4. Furthermore, I'm sure the documentation about this feature will mention the PHP 5.4 requirement "above the fold" of the article.

So for these reasons, I think it's safe to put this PHP-5.4-requiring-feature in Symfony 2.8. I don't think you need to be afraid that Symfony will cross the line many times in the future. The Symfony framework has a core team that's very focussed on it's usage (with the BC promise, easy upgrade paths, etc. as results).

At last, I want to thank you for sharing your worries in such a clear and long comment!

I agree with Wouter - this is a very special situation - so don't worry@SoboLAN, we take this thing quite seriously.

Btw, nothing depends on this class in Symfony, it's a total extra feature. If you want it on 5.3, you can safely copy this class and tweak it to work with 5.3.

Cheers!

Plus, to add another argument, this feature is mostly for new projects, and I doubt that developers creating new projects will use an old PHP version.

I totally agree with@SoboLAN.

@wouterj@weaverryan what you say is true and reasonable. But at the same time I find@SoboLAN's comments very reasonable too. If some code claims 5.3 compatibility, I understad that it's for its entire codebase.

gedmo/doctrine-extensions has a PHP requirement of>=5.3.2 and it has traits. If you don't want to use them, you don't have to, and your code won't break.

It's been already said:

• 95% of the people that are going to use Symfony are not going to use this trait
• nothing depends on this class in Symfony, it's a total extra feature
• this feature is mostly for new projects

For me, these reasons are enough to keep it in the 2.8 branch

Btw we already had traits in symfony before (ContainerAwareTrait). Not sure what the goal of this discussion is. Nobody forces you to use it.

@Pierstoval@Tobion I totally understand what you're saying. No one is making you use these features.

But the problem in these situations is that you may use some classes/functionalities without knowing it.

Let's take a simple example and say that I have the following line in one of my Controllers:

$this->get('validator')->validate($someObject,array('group1','group2'));

I'm not using what I'm not supposed to. But, behind the scenes, how much is going on in order to validate that object ? You have to:

• build the validator object (which isnot very simple)
• let's say read avalidation.yml file
• interpret the file
• have the Validator go through it and determine which constraints contain those specified groups
• apply those constraints
• build violation errors
• etc.

There are probably thousands of lines of code being executed inside that 1 line from above.

If somewhere in all that code you add code (like for example a trait) that is not compatible with what PHP version you specify in composer, then my project will maybe fail, usually in ways that can be difficult to reproduce.

@Pierstoval@Tobion I only presented above the reason for why this whole discussion started.

@wouterj assured me that something like this would never happen. I hope he's right. I'm very familiar with Symfony's promise to have excellent backwards-compatibility. I will just have faith that bad scenarios like the one above will never happen :) .

I hope I did not piss people off with my concerns. If I did, it was not my intention. I was just somewhat worried.

@SoboLAN Symfony does not rely on the MicroKernelTrait, which means it's true that Symfony works with 5.3. No project is going to break because we added the trait.
If someone or some lib start relying on the trait to provide some feature, then it's their responsibility to enforce the correct minimum PHP version.