Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:10716 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 64151 invoked by uid 1010); 22 Jun 2004 17:16:23 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 64015 invoked by uid 1007); 22 Jun 2004 17:16:23 -0000 Message-ID: <20040622171622.64014.qmail@pb1.pair.com> To: internals@lists.php.net References: <20040622164209.23239.qmail@pb1.pair.com> <5.1.0.14.2.20040622180046.02e53768@127.0.0.1> Date: Tue, 22 Jun 2004 10:15:34 -0700 Lines: 37 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Posted-By: 169.229.135.175 Subject: Re: [PHP-DEV] Bug 28879: Populating arrays with resources and objects as offsets From: pollita@php.net ("Sara Golemon") > > http://bugs.php.net/28879 > > > This isn't a bug fix, but the behavior we chose. > Basically only integers and strings are supported as array offsets. > As you guessed, we converted doubles and bools to integers (possibly > loosing info in doubles). > As resources is something abstract, I'm not really sure we should "fix" > this. Then again, it probably can't do much harm. > For myself, I agree with you. Using resources as array offsets just feels wrong, and I'm more than happy to leave that be. My only concern there was consistency with $arr[$res] = $val; behavior which *does* pickup the lval and has since ages long past. But since there's no BC need to allow resources in array initialization, then sure, leave it to the scripter to cast it to an int if that's REALLY what they want. (Again "why?" comes to mind). > Objects can't be converted to integers because two different objects can > have the same object id! I mentioned it a few times on this list. > Nor would I suggest we do that. The portion of that bug report which refers to objects is only asking why an error is thrown in $arr[$obj] = $val; style while $arr = array($obj => $val); simply fails silently. Here my reservation would be in throwing errors where there previously wasn't one (this would apply to both Objects and Arrays as offsets). If this kind of scripting error is going to cause that name/value pair to simply be ignored however, then it seems as though some notification should be raised. The $arr[$obj] = $val; style raises E_WARNING, so it makes sense (to me) to do the same with the $arr = array($obj => $val); syntax. -Sara