Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80249
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.11.1501070959000.4080@whisky.home.derickrethans.nl>
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>
	<alpine.DEB.2.11.1501070959000.4080@whisky.home.derickrethans.nl>
Date: Wed, 7 Jan 2015 02:18:57 -0800
Message-ID: <CAEZPtU67htboPTt6PefLaEREbkobnPY=BpjKpRGg3B1o8xC0Vg@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: PHP internals <internals@lists.php.net>, Sara Golemon <pollita@php.net>, 
	Stanislav Malyshev <smalyshev@gmail.com>, =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@tekwire.net>, 
	Benjamin Eberlei <kontakt@beberlei.de>
Content-Type: multipart/alternative; boundary=001a1139c2fc5e744e050c0d4087
Subject: RE: [PHP-DEV] [RFC] Extension Prepend Files
From: pierre.php@gmail.com (Pierre Joye)

--001a1139c2fc5e744e050c0d4087
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,
On Jan 7, 2015 5:02 PM, "Derick Rethans" <derick@php.net> wrote:
>
> On Tue, 6 Jan 2015, Fran=C3=A7ois Laupretre wrote:
>
> > > De : Pierre Joye [mailto:pierre.php@gmail.com]
> >
> > > 2. We have no easy way to actually release and deploy adhoc scripts,
> > > used by a given extension
> > >
> > > For 2., it is one of the thing I can imagine implementing in pickle.
> > > Or even better add it a s part of the build scripts and macros. Eithe=
r
> > > will work, even for binary install on windows f.e.. I would really
> > > like to define a clear location relative to the extension directory.
> > > This location will be used by this new feature, if implemented. I als=
o
> > > think that it should be either part of the current prepend setting, b=
y
> > > default and system only, or another setting. What I really consider a=
s
> > > a bad practice is any kind of bundling scripts in the extensions, tha=
t
> > > will be a real pain to maintain and it opens some unknown can of
> > > worms. Distros may also prefer to have that script outside the
> > > extension, easier for cherry picks update when necessary (f.e.
> > > security fixes).
> >
> > I am sorry to say that but, with all due respect, I have a totally
opposite opinion.
> >
> > IMHO, this PHP code (and any other data we want to embed) is an
> > integral part of the extension. A compiled extension is a consistent
> > piece of code, it is contained in a single file and should not be
> > split to separate files.
>
> That's very much the case. One extension, one "install". It doesn't
> matter whether some of the extension is written in C, and other parts in
> PHP. HHVM is *all* about this. Making use of C where you need it, and
> otherwise just write the simpler *but integral* border functionality in
> PHP for faster maintenance and development.

It is not correct nor relevant to compare hhvm extension development with
this case. With hhvm it ends up with an actual native extension while here
it is proposed to bundled script that will be executed at runtime like any
other script, except that nothing can be done with them, not even disable
them if not required (like using its own glue codes).

Even zephir provides easy way to develop extension and again, it ends up
with native code.

The more arguments being brought in this thread the more I am convinced
that we are trying to tackle the wrong problems.

--001a1139c2fc5e744e050c0d4087--