Polyfill Symfony

[Roland Franssen :)]

i think symfony/polyfill would be a great place to add polyfills for symfony itself. Typically this approach eases supporting multiple versions of symfony for bundle/lib/vendor authors.

The function service() vs ref() was mentioned today on slack, but we had a similar problem with bundle Configuration class (the getRootNode) and what not :)

I think we could do it like php thus, symfony/polyfill-sf44, symfony/polyfill-sf51, etc.

An example implementation would be

if (!function_exists('sf\di\service') && function_exists('sf\di\ref') {
  namespace sf\di {
    function service() { return ref(); }
  }
}

The benefit of this approach, IMHO, is we create a central place for such "tricks", whether it's a polyfill or some util code; the goal is to ease migrating all sf required components/bundles/etc. Sharing approaches, best practices, etc.

Thoughts? Worth it?

[Grégoire Paris]

Worth it?

Maybe yeah, let's try to list more things that could go in there.
Recently @franmomu copied this method from the DoctrineBundle to SonataAdminBundle (during sonata-project/SonataAdminBundle#6369):

https://github.com/doctrine/DoctrineBundle/pull/1160/files#diff-850942b3ba24ab03a40aaa81b6152852R689-R711

I think that would also qualify.

I also vaguely remember some bc-layer for the changes in the translator interface or event-dispatcher interface, but cannot find it…

Should we have polyfills for all of Symfony, or for components, or maybe for both? I'm thinking symfony-polyfill-sf-di-44 might be better…

[Nicolas Grekas]

The function service() vs ref() was mentioned

This example is a good one: both functions do exist already, there's no need to polyfill ref(), isn't it? Yes it triggers a deprecation, but that's the point, encouraging ppl to move on. Having a polyfill with no deprecation would be counterproductive IMHO.

Also, I fear this would take too much time to maintain in general.

I'd suggest maintaining this in another org, eg fos, so that the Symfony project itself doesn't have to maintain this. The current process around bc layers is enough a burden, no need to make it even heavier for the project itself IMHO.

[Roland Franssen :)]

there's no need to polyfill ref(), isn't it?

nope, we only provide forward compatibility.

i figured we cannot provide arbitrary utility code, as it breaks the polyfill promise (e.g. if a user replaces the polyfill in the root package due minimum deps being met, such code would break)

i do think symfony/polyfill is the goto repo for, well, polyfills. Personally i prefer a streamlined approach in the symfony org (e.g. symfony/bc-utilities could work), but it'll be a community driven initiative either way.