Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69678
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.180 as permitted sender)
Message-ID: <52613165.8060001@gmail.com>
Date: Fri, 18 Oct 2013 14:02:29 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: internals@lists.php.net
References: <525C631E.1050008@gmail.com>	<CAF+90c9z6Xx8GY8zPvg8x0b953oyxfBV=_5znWVX7OG4Rb7oaQ@mail.gmail.com>	<52610FFE.7020806@googlemail.com>	<CAF+90c-q50p-o_p1VJDC7hLW=Cm5CVDrAy=Ud4g6SFF4bd-6Tg@mail.gmail.com> <CAH-PCH4b9K7F_ohOs7uvxHoC9soXfkZbx900393Qo_hewRDEJQ@mail.gmail.com>
In-Reply-To: <CAH-PCH4b9K7F_ohOs7uvxHoC9soXfkZbx900393Qo_hewRDEJQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Proposal to deprecate create_function()
From: rowan.collins@gmail.com (Rowan Collins)

On 18/10/2013 13:39, Ferenc Kovacs wrote:
> I've only skimmed through the thread, but did somebody already proposed
> changing the return value of create_function to return a closure instead of
> deprecating it?

I mentioned it briefly in my initial post, but felt that unless BC was 
100%, it wasn't worth it, as you couldn't guarantee which of the current 
behaviour people were relying on.

People can always write a version in PHP which is good enough for their 
particular requirements.

> If we really we want 100% compatibility, we could even add a __toString to
> the Closure object with an internal function name (similar was proposed by
> Joe for anonymous functions and I listed it as a con, because not matching
> the current behaviors of Closures) through which it can be called as a
> string while throwing a STRICT/DEPRECATED error so people can move away
> from manipulating the return value as a string, and we can remove that
> behavior later on.

That's an interesting idea, although I'm not sure about adding a feature 
and immediately deprecating it. It seems like if closures had a 
__toString, people would start to use it, so we would have to assume 
that the feature was there to stay.

Another thought I had was to implement a safer version of 
create_function() under a different name, and provide a PHP-level 
implementation which ran under old versions for forwards-compatibility. 
You could, for instance, take an associative array of variables to close 
over, which would be equivalent to the use() statement if implementing 
on top of closures, and use var_export() to interpolate into a legacy 
create_function() implementation:

usort(
     $some_array,
     create_eval_closure(
// args, as name only; would lack of default value support be a problem?
         array('a', 'b'),

         // function body, as a static string
         'return strcasecmp($a[$key], $b[$key]);',

         // variables to "close over"
         array('key' => $key)
     )
);

Basically, it would be a bit like a parameterised SQL query: you can't 
actually prevent people interpolating into the strings anyway, but you 
can give them a safe mechanism that means they shouldn't need to.

-- 
Rowan Collins
[IMSoP]