On Jan 6, 2015 9:53 PM, "Benjamin Eberlei" <kont...@beberlei.de> wrote: > > > > On Tue, Jan 6, 2015 at 3:50 PM, Pierre Joye <pierre....@gmail.com> wrote: >> >> >> On Jan 6, 2015 9:20 PM, "François Laupretre" <franc...@tekwire.net> wrote: >> The whole code to consider as part of an extension, whatever the language, must be kept in sync. And the best way to achieve this is to store it in a single file. >> >> I would rather say in a single release and package. Built in scripts in an extension is an extremely bad step, maintenance, issues management and all possible complications to allow that may bring. But we get each other view. I only hope we will not do that. >> >> Also interesting to ignore the other questions, which are imho very critical. :) > > How is shipping php code inside so/ddl worse than shipping just the C code this way? I agree with you it makes changing the PHP code more difficult (requires recompile), but it makes the deployment and build much simpler. Including the security concerns.
It does not make the builds simpler, in contrary. From an initial release point of view, no change. However for any other release, it changes a lot. The glue code may change more often (it does for a few of my exts f.e.), updates process are then totally different, from a packaging and deployment point of view. >From a core php point of view, it needs this new feature, I never had the need of it while having done glue code as part of releases for quite some time. It introduce something radically different and not as simple as it may sound. I have doubt a about the gains given the costs. Let alone the total lack of flexibility, be for the support (pls try that patch) or customizing of the glue codes. Customizations can still be done but the upstream versions will always be loaded, whatever it does (and could prevent customization in some cases fe.) I also wonder why php needs that while any other similar languages have chosen to improve the packaging and default installation to drastically ease pkg made of native and scripts codes (see python or Perl for example). And a details but why it needs to be "bundled to be faster" but it is used for non performance critical parts? While this argument may switch to "easier to have all synced" :) Remains the other points I mentioned, what's about making user exposed classes&co from internal more friendly? What about the alternative solution? Default location etc? Or are we going to see again a RFC not taking of the Comments and go with a single option vote? (Just to prevent that to happen again)
