Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:9729
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <5.1.0.14.2.20040508101008.02496d28@127.0.0.1>
Date: Sat, 08 May 2004 10:12:26 +0300
To: "Sara Golemon" <pollita@php.net>,internals@lists.php.net
In-Reply-To: <20040508013742.56415.qmail@pb1.pair.com>
References: <20040507210516.92262.qmail@pb1.pair.com>
 <20040507210516.92262.qmail@pb1.pair.com>
 <5.1.0.14.0.20040507202204.028a1120@mail.ionzoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] Implicit Arrays and E_STRICT
From: andi@zend.com (Andi Gutmans)

Hi Sara,

I don't think any error message should be thrown during implicit array 
creation. Not having to define your variables is one of the main principles 
of the PHP language. I definitely don't think this should be changed. I 
also don't see how this differs very much from a regular assignment to an 
undefined variable (e.g. $var = 2; ).

I think making this an error, even an E_STRICT is a very bad move.
Andi

At 06:39 PM 5/7/2004 -0700, Sara Golemon wrote:
> > > > This topic got quietly dropped last week, but I'd like to make one
>last
> > > > plea.  I'd like to see Zend throw an E_STRICT when arrays are
>implicitly
> > > > created.  I know there were objections to E_NOTICE, but did anyone
>have
> > > > violent objections to E_STRICT?
> > > >
> > >i like to see one of those too and i have no preference for one of them.
> > >
> > I would view implicit array creation as a slightly negative thing, similar
> > to accessing the value of a variable that does not exist.
> >
> > We run in E_ALL mode and write our code to avoid all E_NOTICEs.  For
> > instance, before using an array, I always initialize it using $aItems =
> > array();
> >
> > I'm in favor of issuing an E_NOTICE in response to this.
> >
>As Andi stated in the earlier incarnation of this thread (I think it was
>Andi), making an E_NOTICE will cause sudden errror generation in previously
>E_ALL safe code.
>
>While I *personally* would rather see E_NOTICE used, I can certainly
>understand the desire to tread lightly on what has long been considered a
>"feature" of PHP.  That's why I think that E_STRICT qualifies as an
>effective compromise between encouraging good coding practices and avoiding
>BC breaking changes which add little to actual scrript execution.
>
>-Sarra
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php