As we (Liip) have mentionned previously, we would like to backport the
2.0 namespaced code of the DI component to the sf1 style, for PHP < 5.3
support.
To do so, I would like to request commit access, although that can wait,
but also I would like to know if anyone has a preference as for how to
call the classes.
My plan is to replace namespace Symfony\Components\DependencyInjection
by an sfServiceContainer prefix, keeping most of the BC with the current
version I hope.
Other than that, there are just two closures to be ported and the rest
should hopefully work as is.
Then we may try to make some changes [1/4] but ideally we would push
those in the 2.0 and then backport, to keep everything in sync and have
the two version be as interchangeable as possible.
Cheers,
Jordi
[1] http://trac.symfony-project.org/ticket/7569
[2] http://trac.symfony-project.org/ticket/7677
[3] http://trac.symfony-project.org/ticket/7645
[4] http://trac.symfony-project.org/ticket/7648
> Heya,
>
> As we (Liip) have mentionned previously, we would like to backport the
> 2.0 namespaced code of the DI component to the sf1 style, for PHP < 5.3
> support.
>
> To do so, I would like to request commit access, although that can wait,
> but also I would like to know if anyone has a preference as for how to
> call the classes.
I might already have commit access. I am not sure if I do, but Jordi is actually the one who will spend more time on this than I will.
> My plan is to replace namespace Symfony\Components\DependencyInjection
> by an sfServiceContainer prefix, keeping most of the BC with the current
> version I hope.
I talked with Jordi about this and it seems for the components like the request handler, the service container and the templating (note: we do not use the templating component at Liip) to just move them to the 2.0 CS in order to have things be easier to sync up. the yaml and event components will obviously remain in the old CS, since they will be maintained as part of symfony 1.x
regards,
Lukas Kahwe Smith
m...@pooteeweet.org
I should also note that we will both be at the conference next week in Paris, but since our talk is about integrating components, it would be good to move this discussion along before then, so that we can give some answers during our presentation :)
regards,
Lukas
Send me your trac username and I will add you as a commiter.
>
> My plan is to replace namespace Symfony\Components\DependencyInjection
> by an sfServiceContainer prefix, keeping most of the BC with the current
> version I hope.
>
> Other than that, there are just two closures to be ported and the rest
> should hopefully work as is.
>
> Then we may try to make some changes [1/4] but ideally we would push
> those in the 2.0 and then backport, to keep everything in sync and have
> the two version be as interchangeable as possible.
>
> Cheers,
> Jordi
>
> [1] http://trac.symfony-project.org/ticket/7569
I'm not sure why I have not implemented it. Propably because it can
cause some problems with dependencies, and caches. But I'm not sure.
> [2] http://trac.symfony-project.org/ticket/7677
I have explicitly forbid references in parameters in the PHP 5.3
version, mostly because most of the time, there are workarounds for
that, and also for performance issues.
> [3] http://trac.symfony-project.org/ticket/7645
This has been fixed in the PHP 5.3 version
> [4] http://trac.symfony-project.org/ticket/7648
This has been fixed in the PHP 5.3 version
Fabien
>> [1] http://trac.symfony-project.org/ticket/7569
>
> I'm not sure why I have not implemented it. Propably because it can cause some problems with dependencies, and caches. But I'm not sure.
Its a tricky feature in a way we are asking for. It really has no place inside normal use and could give people bad ideas. At the same time for our use case caching etc isnt really a concern as its for testing anyways where we do not want to cache.
>> [2] http://trac.symfony-project.org/ticket/7677
>
> I have explicitly forbid references in parameters in the PHP 5.3 version, mostly because most of the time, there are workarounds for that, and also for performance issues.
Are you performance concerns based on adding that single if statement?
Anyways I have to review the specific use case. It might indeed be solveable by simply backporting optional dependencies.
Seldaek it is, thanks ! BTW are the commits still happening in svn and
then synced to git or is it the other way around now?
>> [1] http://trac.symfony-project.org/ticket/7569
>
> I'm not sure why I have not implemented it. Propably because it can
> cause some problems with dependencies, and caches. But I'm not sure.
Well recreating the entire container works for us at the moment, but
it's a lot of overhead so it would be nice if it can be implemented.
>> [2] http://trac.symfony-project.org/ticket/7677
>
> I have explicitly forbid references in parameters in the PHP 5.3
> version, mostly because most of the time, there are workarounds for
> that, and also for performance issues.
Sounds sensible, maybe it would be possible to have something like :
services:
logging:
class: %logger%
And if %logger% is set to null or false, it just wouldn't create it ?
That way you don't need references for objects, but you only pass the
classname or false.
>> [3] http://trac.symfony-project.org/ticket/7645
> This has been fixed in the PHP 5.3 version
>
>> [4] http://trac.symfony-project.org/ticket/7648
> This has been fixed in the PHP 5.3 version
Awesome.
Cheers,
Jordi
No Seldaek found. Are you sure this user exists in the symfony trac?
The 2.0 branch is synced from Git to SVN every 15 minutes. Everything
else is still on Subversion as a master.
Fabien
I created it last week to report a sf1.4 issue [1], and I'm logged in
right now, so yes I'm pretty sure.
Cheers,
Jordi
>> [3] http://trac.symfony-project.org/ticket/7645
>
> This has been fixed in the PHP 5.3 version
You didnt reference the ticket in your commit. How did you address this issue?
http://github.com/symfony/symfony/commit/53980bb55e9f2b5c321d24e40f8491b72708a154