[RFC] Closures: updated proposal and patch View as Markdown

Looking through the closures patch, I would tend to agree. GC has
certainly caused us way more headaches in APC-land than closures will,
from the looks of it.

-Rasmus

Dmitry Stogov wrote:

I don't see big problems with closures. The patch is simple and stable.
It's main part isolated in zend_closures.c and it doesn't affect other
parts of engine.

I expect more problems with GC

Thanks. Dmitry.

Andi Gutmans wrote:

I think given closures is in a pretty fully baked state (we had an
exemplary process) the main questions to ask are:
a) Assuming we are going through numerous beta and RC cycles for PHP
5.3, do we think that the time it would take for other features like
namespaces, garbage collector to be fully tested and stabilize would
allow for closures to stabilize too in that same time frame (i.e. would
not push out a final release date for PHP 5.3)?
b) Are the release managers willing to manage an additional major
feature as part of the release process?

I am not stating my opinion here because I could go either way although
ultimately my bias is not to postpone a feature freeze nor a final
release so it's really up to the release managers to decide on (1) and
(2).

Andi

-----Original Message-----
From: Dmitry Stogov [mailto:dmitry@zend.com]
Sent: Thursday, July 03, 2008 12:27 AM
To: Lukas Kahwe Smith
Cc: Christian Seiler; php-dev List
Subject: Re: [PHP-DEV] [RFC] Closures: updated proposal and patch

Hi Lukas,

From my point of view the proposed closures concept is very consistent
and implementation doesn't complicate the engine at all. The code
without closures will work without any changes, but code with closures
(instead of eval() and create_function()) will work significant faster
as lambda function will be stored in opcode caches. Opcode caches
don't
even need to be modified to do that.

BTW: I see you point of view and it makes sense. It's just pity that
we
will need to wait for closures additional year(s).

Thanks. Dmitry.

Lukas Kahwe Smith wrote:

I've spoken to Dmitry and he said the patch will be committed to
HEAD
soon. Since both Dmitry and I still want to have it in 5_3 too,
we'd
want to ask for opinions on this again - especially since after
quite a
lot of thorough review and discussion on this list basically all
the
side-effects have been addressed and there are now quite a few
tests
that ensure the correct behaviour of closures. Also, the patch is
now
built in a way that the main functionality remains inside
zend_closures.c, so any possible not yet encountered bug can be
fixed
without breaking binary compability.
I talked to Johannes about this. It does indeed seem like this
feature
is in a very solid stage at this point. However the current version
of
the patch is still young. Also we already have such an insanely long
list of new big features, that anything that will take even the
slightest focus away on getting this long list rock solid will have
to
wait until 5.4. Even the most rock solid proposal is bound to have
some
small issues after all.

So as things look atm, closures will have to wait until then. But
cool
features like closures, traits etc will undoubtedly increase the
incentive to get working quickly on 5.4 and this can happen as soon
as
we have 5.3 out the door and working well for our user base.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

Hi,

I don't see big problems with closures. The patch is simple and
stable.
It's main part isolated in zend_closures.c and it doesn't affect other
parts of engine.

Changes too the languages always introduce some side effects and
therefore we have too be careful there. Even stuff which is from engine
point of view nice might have some effects on the userland which might
not be too nice, just see the ongoing discussions about details about
namespaces... But back to closures:

I spent the last weeks with less mail reading and am still 112 mails on
internals behind so maybe I missed something there but even short tests
showed me things which might need cleanup:

A tiny thing I saw is different naming in different places:

php -r 'is_callable((function () {}), true, $name); var_dump($name);'
string(6) "lambda"

vs.

php -r 'var_dump(function(){});'
object(Closure)#1 (0) {
}

Do we really want to use both names in userland? Is a string "lamda"
really the best represantation for callable_name? (this might even be an
issue if somwbody has a function called lambda ... for whatever reason,
oh just checked people even do:
http://google.com/codesearch?hl=en&lr=&q=lang%3Aphp+%22Function+lambda(%
22&sbtn=Search )

Another issue I found during my short testing period today is
reflection: In a previous position I had to deal with callbacks, for
making the code more robust I checked the callback using reflection
before accepting it, the code looks something like that:

function setCallback($cb) {
if (is_array($cb) {
$r = new ReflectionMethod($cb);
} elseif (is_String($cb)) {
$r = new ReflectionFunction($cb);
} else {
throw new Exception();
}

   if ($r->getNumberOfRequiredParameters() != 2) {
       throw new Exception();
   }
   /* ...  morre checks of that kind ... */
}

Now such a check isn't possible, all reflection information on the
callback I can get is that it is an object of type Closure having a
method __invoke() with zero required parameters. There's no further
information on the function, so probably we need a ReflectionClosure
class or something

Both of them are tiny issues which can be fixed in a quite simple way
(or be documented as expected) but my concern is that we'll find way
more of them.

So the final question is: Do we want to go in a higher pace to get
things out and have other features ready which can be added early for a
new release cycle or do we want to go a bit slower with the risk of
stopping and probably going backwards, again.

I'd prefer the first way (even so I do really like closures and wanted
to have them for some loooong time...)

I expect more problems with GC

GC can be problematic yes, but imo gc can either be disabled by default
and documented as "use only with care for running your unit test suite"
or completely dropped, even in a later stage if there are problems, I
don't see there much potential for long going detail discussions. Even
if it's, technically, more critical.

johannes

I don't see big problems with closures. The patch is simple and stable.

While you're probably right, it seems there is still lots of discussion
about how closures should work. It seems better to get this right in a
later version than to jam it in 5.3 just because it will be out sooner.

--Dan

--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409

Absolutely agree.

I don't see any reason for 5.4. We don't plan any significant new
features.
You guys are scaring me ..
I was hoping to evade such discussions. PHP 5.3 is probably the
minor version release with the most major changes ever. Mostly
because we waited too long to go into release mode. PHP 6 has of
course lingered even longer and it really really needs to get out
the door ASAP. Now what I would propose is that we go into release
mode on PHP 6 as well. Due to the nature of it being a major version
bump it will naturally take longer to get completed. Depending on
how quickly we move with PHP 5.3, we will then either release a PHP
5.4 with all of the open items before PHP 6 or more or less at the
same time.

But if we put the burden of being the last planned PHP 5 release
onto 5.3, we will have huge issues getting it out the door. So
please let us keep 5.4 on the table, but at the same time do
everything we can to get PHP 6 onto some sort of "release schedule".

I have emailed Andrei about this offlist when I saw Derick's email.
But I just wanted to send this email as a sort of damage control :)

A loud +1 to this from me. Can we get an RFC into the Wiki on this?

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

Lukas Kahwe Smith skrev:

But if we put the burden of being the last planned PHP 5 release onto
5.3, we will have huge issues getting it out the door. So please let us
keep 5.4 on the table, but at the same time do everything we can to get
PHP 6 onto some sort of "release schedule".

Let me see if I get this.

PHP 5.4 = 6.0 without Unicode.
PHP 6.0 = 5.4 plus Unicode.

It sounds like PHP 5.4 is actually needed when 6.0 no longer has the
Unicode semantics on/off switch.

FWIW, personally, I need Unicode more than I need namespaces; I need
Unicode more than I need traits; I need Unicode more than I need lambda
and closures. I need Unicode more than I need {$capability_of_choice}.
All of those things are nice, but Unicode is getting critical.

Lars Gunther