Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:69655 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 25723 invoked from network); 17 Oct 2013 19:23:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Oct 2013 19:23:22 -0000 Authentication-Results: pb1.pair.com header.from=php@marc-bennewitz.de; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=php@marc-bennewitz.de; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain marc-bennewitz.de from 80.237.132.171 cause and error) X-PHP-List-Original-Sender: php@marc-bennewitz.de X-Host-Fingerprint: 80.237.132.171 wp164.webpack.hosteurope.de Received: from [80.237.132.171] ([80.237.132.171:50139] helo=wp164.webpack.hosteurope.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 97/77-12663-82930625 for ; Thu, 17 Oct 2013 15:23:21 -0400 Received: from dslb-088-072-003-062.pools.arcor-ip.net ([88.72.3.62] helo=[192.168.178.27]); authenticated by wp164.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) id 1VWtAD-0000dD-0p; Thu, 17 Oct 2013 21:23:17 +0200 Message-ID: <52603923.7010808@marc-bennewitz.de> Date: Thu, 17 Oct 2013 21:23:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: internals@lists.php.net References: <525C631E.1050008@gmail.com> <1381853515.3980.195.camel@guybrush> <526002B4.9010808@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-bounce-key: webpack.hosteurope.de;php@marc-bennewitz.de;1382037801;3b7c9d02; Subject: Re: [PHP-DEV] Proposal to deprecate create_function() From: php@marc-bennewitz.de (Marc Bennewitz) Am 17.10.2013 17:47, schrieb Pierre Joye: > On Thu, Oct 17, 2013 at 8:31 AM, Rowan Collins wrote: >> On 15/10/2013 17:11, Johannes Schlüter wrote: >>> >>> In general: Getting rid of it is good. But mind that closures are no >>> full replacement as with create_function() the code can be created on >>> the fly. >> >> >> Yes, I agree that there is no trvial solution which is 100% feature (and >> bug) compatible with create_function(). However, I think the more important >> question is whether there are any particular *use cases* which can't be >> easily migrated to a different mechanism. > > That's the actual question, why should they? > > >> My gut feel is that at least 95% of uses of create_function are to create >> dynamic callbacks for usort, preg_replace_callback, array_filter, etc. For >> these uses, the implementation as an eval() is a liability, and >> reimplementing with real closures is trivial (assuming no need to run on >> <=5.2). > > Yes, as many other new features allow cleaner codes. However I do not > see this case as good enough to add more deprecated notices to > perfectly valid codes. Please note that there are open bugs with "create_function" the should than be fixed including memory issue. > > Cheers, >