Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80238
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEPJdunFNFD1MocVX2n4koefaDMciBhP7QNpRJo=W0Yonq8aOw@mail.gmail.com>
References: <CAEPJdu=2oWiSCQOTkO1g5QDs4NrJwd5H14Jks17qrNu7-eQNVg@mail.gmail.com>
	<CAESVnVqAHJujo0anMi7QYhSZeErcfRVAJ=M7oQMG-huk-bxpCg@mail.gmail.com>
	<54AAF98B.4020709@gmail.com>
	<alpine.DEB.2.11.1501061120440.4080@whisky.home.derickrethans.nl>
	<CAEZPtU69a2MwH5aqigAUEp8+KcjR+w9pd81EvzvM1_z4ES34rQ@mail.gmail.com>
	<001b01d029bb$fa687fc0$ef397f40$@tekwire.net>
	<CAEZPtU5xQWZSdVoV9RVVJX+snZ8YVxMctt0N4vXEDeQpkTAcMQ@mail.gmail.com>
	<CAEPJdunFNFD1MocVX2n4koefaDMciBhP7QNpRJo=W0Yonq8aOw@mail.gmail.com>
Date: Tue, 6 Jan 2015 07:07:30 -0800
Message-ID: <CAEZPtU7apR=r3SvszpA0LYs7XXFyY-S6BGQuCygGymCaQ_qo-A@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Cc: Stas Malyshev <smalyshev@gmail.com>, Sara Golemon <pollita@php.net>, 
	Derick Rethans <derick@php.net>, PHP internals <internals@lists.php.net>, francois@tekwire.net
Content-Type: multipart/alternative; boundary=001a1139b508737f5a050bfd2ade
Subject: Re: [PHP-DEV] [RFC] Extension Prepend Files
From: pierre.php@gmail.com (Pierre Joye)

--001a1139b508737f5a050bfd2ade
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Jan 6, 2015 9:53 PM, "Benjamin Eberlei" <kontakt@beberlei.de> wrote:
>
>
>
> On Tue, Jan 6, 2015 at 3:50 PM, Pierre Joye <pierre.php@gmail.com> wrote:
>>
>>
>> On Jan 6, 2015 9:20 PM, "Fran=C3=A7ois Laupretre" <francois@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)

--001a1139b508737f5a050bfd2ade--