Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54304
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4E3898B0.40809@sugarcrm.com>
References: <CACs9DU4jhCBHEYXd-N1rvYE5jbCDztvXEi=gsZh4ozLoqQrRXw@mail.gmail.com>
	<CAEZPtU7dB9-ATrKqNF_sk+aeEPuKBZCFxYiZ41T1QSy4xgKLYw@mail.gmail.com>
	<CACs9DU6MAmJt6veeOEVdkL5spO+8YVgmvbhioc7ORWZH-1d1LQ@mail.gmail.com>
	<4E3898B0.40809@sugarcrm.com>
Date: Wed, 3 Aug 2011 03:25:07 +0200
Message-ID: <CACs9DU4Z2ZR+VkbZoQry=N6WJqR1ZemkODiG7QeUvKNS_d_UHQ@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>, internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [VOTE] Weak References
From: landeholm@gmail.com (Hannes Landeholm)

Hello Stas,

On 3 August 2011 02:39, Stas Malyshev <smalyshev@sugarcrm.com> wrote:>
> I notice some tone of hostility here.

I'm not hostile. Perhaps a bit disappointed that the PECL objection
wasn't brought up earlier in the discussion period so It could have
been toughly discussed.

> /* snip */
> This is why we tend to recommend to try the code outside the core if
> possible before taking it in.

Yes, this is self evident.

> You seem to regard PECL as some kind of place where code goes to die. This
> is not so. Of course, some PECL extensions do wither and die of neglect, but
> others work just fine and have large user base - such as memcache support,
> apc, etc. Recommendation of PECL is not a punishment or disregard for your
> ideas or code - it is a recognition of the fact that not every new idea
> should immediately be implemented in the core.

See the first paragraph in my previous post.

> If you think all proposals are more complex than this, you are obviously
> wrong. Most of recently added things into 5.4 in fact are conceptually
> simpler.

Weak Reference: An object reference that does not prevent GC. I can't
imagine something more conceptually simple although the use cases are
not very simple. I don't think it's obvious why I am "obviously
wrong".

> Rapid release cycle doesn't mean that we immediately put into the release
> everything that was proposed up to the last second when it's supposed to be
> released.

I'm referring to the fact that PHP has a major update once a year.
Looking at it from an agile perspective this is insanely slow. I think
you should use smaller iterations and release faster. The new Mozilla
release schedule is a good example.

> If you need a solution for your use cases, I don't see how PECL extension wouldn't be fine.

I have no problem compiling extensions and I also don't have any
customers on share hosting. Although it wastes a bit more of my time
I'm personally fine with PECL. I'm contributing to open source though
so I'm concerned with the users that won't be able to run my code
because they can't install PECL extensions. I'm also worried that it
will takes years for WR to be moved to the core and that nobody will
notice or use it. PHP deserves weak references. Not in a year but
today.

~Hannes