Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69675
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c-q50p-o_p1VJDC7hLW=Cm5CVDrAy=Ud4g6SFF4bd-6Tg@mail.gmail.com>
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>
Date: Fri, 18 Oct 2013 14:39:44 +0200
Message-ID: <CAH-PCH4b9K7F_ohOs7uvxHoC9soXfkZbx900393Qo_hewRDEJQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Crypto Compress <cryptocompress@googlemail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf303ea4b8a25e8404e9033aab
Subject: Re: [PHP-DEV] Proposal to deprecate create_function()
From: tyra3l@gmail.com (Ferenc Kovacs)

--20cf303ea4b8a25e8404e9033aab
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 18, 2013 at 2:19 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Fri, Oct 18, 2013 at 12:39 PM, Crypto Compress <
> cryptocompress@googlemail.com> wrote:
>
> > Hello,
> >
> > shure all things can be replaced with more and verbose code. What is th=
e
> > benefit of writing all this lines in contrast to one method call?
> > https://github.com/phpcr/**phpcr-utils/blob/master/src/**
> > PHPCR/Util/Console/Helper/**PhpcrCliHelper.php#L111<
> https://github.com/phpcr/phpcr-utils/blob/master/src/PHPCR/Util/Console/H=
elper/PhpcrCliHelper.php#L111
> >
> >
> > -1 for removing wrappers/abbreviations/and such
> > +1 for bugfixing
> >
> > Best,
> > CC
> >
>
> Could you maybe elaborate a bit on your use case there? I.e. provide some
> context as to why the create_function call there is necessary and why it
> can't be replaced with use of anonymous functions (and maybe also what
> additional constraints there are). For people like myself that are not
> familiar with the exact workings of that library.
>
> Thanks,
> Nikita
>

I guess he is trying to say that writing a factory method for producing
callable/anonymous functions are easier with create_function than with
closures, because you call eval implicitly, instead of explicitly.

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?
That way we could keep bc and remove the ugly null-prefixed hidden function
from the global function table.
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.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--20cf303ea4b8a25e8404e9033aab--