Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:54297 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 4969 invoked from network); 2 Aug 2011 21:32:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Aug 2011 21:32:39 -0000 Authentication-Results: pb1.pair.com header.from=chrisstocktonaz@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=chrisstocktonaz@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.170 as permitted sender) X-PHP-List-Original-Sender: chrisstocktonaz@gmail.com X-Host-Fingerprint: 209.85.210.170 mail-iy0-f170.google.com Received: from [209.85.210.170] ([209.85.210.170:55087] helo=mail-iy0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7B/A1-30104-6FC683E4 for ; Tue, 02 Aug 2011 17:32:39 -0400 Received: by iym1 with SMTP id 1so211965iym.29 for ; Tue, 02 Aug 2011 14:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vLhocOL5d4zee7oNiBQfZMidtZjq9+cR2nfqadodxUU=; b=EEqZ3LDf/T8jVKc/MytfX8FPcQqzLNr5kITvuap0bCd9LX96uuMgMXGQdNuK+QuIBn RAUT7oGHyI+0wZ7isj89Xpij2HHhvBePcXNeVpuetUkd0JB///fUZTzHj9J1Pf0v/DSQ FjyDHvEwsE2T+jC+Rx+rWJvgQ5Ni54e9a+a/o= MIME-Version: 1.0 Received: by 10.42.196.6 with SMTP id ee6mr4693272icb.206.1312320756172; Tue, 02 Aug 2011 14:32:36 -0700 (PDT) Received: by 10.42.197.132 with HTTP; Tue, 2 Aug 2011 14:32:36 -0700 (PDT) In-Reply-To: References: <4E3814C9.2020407@lsces.co.uk> Date: Tue, 2 Aug 2011 14:32:36 -0700 Message-ID: To: Hannes Landeholm Cc: Lester Caine , internals@lists.php.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [VOTE] Weak References From: chrisstocktonaz@gmail.com (Chris Stockton) Hello, On Tue, Aug 2, 2011 at 11:06 AM, Hannes Landeholm wro= te: > =A0I've talked to Etienne and he still believes we should vote on this so= the > vote is still up. He just replied to quickly. If the vote fails the patch > can still be implemented in a PECL extension. There's no point canceling = the > vote or the RFC - it's still valid and ongoing, and there is still time f= or > discussion. > > .. snip ... I think at this point everyone is well aware that you would like this feature implemented. I would like to make a couple points here, first I is that PECL is not a place for a extension to rot, that statement makes absolutely no sense to me. PDO I recall years ago getting from PECL, Http a extension I often use, was recently on this list if I recall to be moved into the core. I'm sure there are plenty of people on this list that were part of extension's PECL -> CORE lifecycles that could add several more examples to the list. I believe PECL Would be a great place for something like this that was is entirely understood or has overwhelming support in my opinion. I am really not sure how comfortable I am with a feature as new as this being in the PHP on my servers. Some form of incubation, testing and use feedback only makes sense to me. Second I would like to talk a little bit about weak references for those who are not familiar with them or have thus far only read your very strong pro-opinion. I would like to make it very clear with the simple fact that weak references are not required, ever by any language. They are a convenience, not a solution to a unsolvable problem. I believe that if anything weak references encourage laziness in design, it causes the referential integrity that I am accustomed to is broken, and can often lead to more code and checks then it relieves. It is very easy to run into unexpected bugs and in a language like PHP, where you don't get a NPE when you try to access a NULL method of a non object, you get a fatal error, this doesn't seem very appealing to me. Only under very specific cases of caching patterns as you have previously mentioned is such a pattern even recognized to -have a place for use that isn't just plain wrong- -not a requirement- by me. In PHP, I believe a web or cli app that uses enough resources to bomb memory limits on a server, needs to be re-factored. I have definitely written multi-process PHP daemons that go to disk or over the network for taxing operations that need cached and had very little trouble with rudimentary memory management patterns, so from my perspective I can't really see why given the toolset PHP provides that this is such a problem. This is just my opinion, I don't have a strong opposition to this feature, anything "new" to PHP I usually get excited about, I simply wanted to give a few counter arguments as the fact that this feature is being presented as a dire and long over due missing feature to the language is a bit dramatic. Not saying its useless and doesn't belong in PHP or I would never want it to exists, I just would hate to see something rushed through that didn't get a bit of testing and typical QA from a language that affects millions of people. -Chris