Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:80272 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 35948 invoked from network); 8 Jan 2015 11:43:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Jan 2015 11:43:39 -0000 Authentication-Results: pb1.pair.com header.from=derick@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=derick@php.net; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender) X-PHP-List-Original-Sender: derick@php.net X-Host-Fingerprint: 82.113.146.227 xdebug.org Linux 2.6 Received: from [82.113.146.227] ([82.113.146.227:36867] helo=xdebug.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 35/12-21915-96D6EA45 for ; Thu, 08 Jan 2015 06:43:39 -0500 Received: from localhost (localhost [IPv6:::1]) by xdebug.org (Postfix) with ESMTPS id 6116BE202D; Thu, 8 Jan 2015 11:43:33 +0000 (GMT) Date: Thu, 8 Jan 2015 11:43:33 +0000 (GMT) X-X-Sender: derick@whisky.home.derickrethans.nl To: Pierre Joye cc: francois@tekwire.net, PHP internals , Sara Golemon , Stanislav Malyshev , Benjamin Eberlei In-Reply-To: Message-ID: References: <54AAF98B.4020709@gmail.com> <001b01d029bb$fa687fc0$ef397f40$@tekwire.net> <00a201d02ac7$406a4830$c13ed890$@tekwire.net> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-695507503-1420717413=:4080" Subject: Re: [PHP-DEV] [RFC] Extension Prepend Files From: derick@php.net (Derick Rethans) --8323329-695507503-1420717413=:4080 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 7 Jan 2015, Pierre Joye wrote: > On Wed, Jan 7, 2015 at 2:14 PM, Fran=C3=A7ois Laupretre wrote: > >> De : Pierre Joye [mailto:pierre.php@gmail.com] > >> > >> ... here, it is proposed to bundle scripts that will be executed at=20 > >> runtime like any other script, except that nothing can be done with=20 > >> them, not even disable them if not required (like using its own=20 > >> glue codes). > > > > I agree. Bundling scripts in extensions to execute them at each=20 > > RINIT is, IMO, not a good idea (mostly for performance reasons and=20 > > lack of control, as you note), but I keep thinking that a mechanism=20 > > to embed PHP scripts in extensions and make them available via a=20 > > common stream wrapper can be useful. What I don't like is the fact=20 > > to execute them automatically at every RINIT. I prefer to let the=20 > > extension free to load its PHP code when its logic decides it is=20 > > needed. >=20 > Or let the extension defines a script to prepend, preload, whatever we > end to do. >=20 > It is however important, as you mentioned, to leave the engine and the > user the ability not to load it, at all. No no, *not* loading the code is exactly what I want to prevent people=20 from doing! The PHP library code is an *integral* part of the extension.=20 Without it, its APIs and functionality would be useless. pickle, two packages, or any of that other mallargy are not going to fix=20 this. It needs to be one package for this to work well, *without* the=20 possibility of users messing things up. Derick --8323329-695507503-1420717413=:4080--