ge -
> >From: "Andi Gutmans" <[EMAIL PROTECTED]>
> >To: "Sara Golemon" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> >Sent: Tuesday, June 22, 2004 7:02 PM
> >Subject: Re: [PHP-DEV] Bug 28879: Populating arrays with resources and
> >
ssage -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: "Sara Golemon" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, June 22, 2004 7:02 PM
Subject: Re: [PHP-DEV] Bug 28879: Populating arrays with resources and
objects as offsets
> This isn't a b
02 PM
Subject: Re: [PHP-DEV] Bug 28879: Populating arrays with resources and
objects as offsets
> 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 (po
Hi:
On Thu, Jun 24, 2004 at 11:33:54AM +1000, Aidan Lister wrote:
> > 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).
>
> PEAR::DB uses this met
> Maybe we should move this to an E_STRICT? E_WARNING is more consistent
with
> existing warnings but I wouldn't want to be over strict, especially when
> making this change a couple of weeks before release.
> We could escalate the warning for 5.1 if we feel we need to do so.
>
While I have ala
Maybe we should move this to an E_STRICT? E_WARNING is more consistent with
existing warnings but I wouldn't want to be over strict, especially when
making this change a couple of weeks before release.
We could escalate the warning for 5.1 if we feel we need to do so.
Andi
At 11:33 AM 6/24/2004
> 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).
PEAR::DB uses this method - I'm seeing a million errors on sites that have
updated to latest CVS ve
As far as I'm concerned you can go ahead and commit this.
At 09:34 AM 6/23/2004 -0700, Sara Golemon wrote:
> >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] = $v
> >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 n
At 10:15 AM 6/22/2004 -0700, Sara Golemon wrote:
> > 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 double
"Sara Golemon" <[EMAIL PROTECTED]> writes:
> Here my reservation would be in throwing errors where there previously
> wasn't one (this would apply to both Objects and Arrays as offsets).
Prior to release of PHP5 is most certainly the right time to make this sort of
change. There are already othe
> > 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
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 ag
http://bugs.php.net/28879
The fixes are really simple (and the ZE1 branch is no more complicated), but
I just wanted to double check that this kind of behavior change should be
done. On the one hand it makes things consistent (which is good), on the
other hand the two "problems" it "solves" are f
14 matches
Mail list logo
