Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71644
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 198.187.29.241 as permitted sender)
Message-ID: <52E68F04.10502@ajf.me>
Date: Mon, 27 Jan 2014 16:53:24 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <52E55D0F.3030308@ajf.me> <CAGAGxbZAgEf7_FSHqnE=w3Xy=eozfcGzTOgr4QsCw_Uj1_f87Q@mail.gmail.com> <52E59BE8.7070202@sugarcrm.com> <20140127110519.GM14262@phcomp.co.uk>
In-Reply-To: <20140127110519.GM14262@phcomp.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP and case-sensitivity inconsistency in PHP 6
From: ajf@ajf.me (Andrea Faulds)



On 27/01/14 11:05, Alain Williams wrote:
> * there are a few special values that are currently case insenitive, eg: NULL, TRUE.
>    I would suggest that they only be recognised in upper case, eg: null would be
>    invalid. This fits with the meme of constant names being in upper case.

I'd prefer lowercase, myself, but I do think we need consistency in case 
for language keywords as well as identifiers. Perhaps having everything 
lowercase.

> * transition, there must be a lot of code that has (accidental) case
> inconsistencies in function/variable/...  names.  If PHP were not a dynamic
> language (eg C) then this change would be caught at compile time. In PHP a case
> inconsistency is only found when the code is executed. Programs can contain
> blocks of code that are rarely executed - think: rare error recovery.
>
> Something that would help with transition is the option to force variables to
> be declared. If a variable is then used without being declared an error is raised.
>
> We currently have the problem as illustrated below:
>
>      $foo = 'bar';
>      echo "foo=$f00";
>
> With case insensitivity this problem will become worse.
>
> What I propose is something like perl's 'use strict'. This causes a compilation
> error if a variable is used that has not been defined. This pragma applies only
> for the compilation module that it is in; ie it does not apply to 'include'd
> files and so can be done on a module by module basis.
>
> The way that I suggest that we do this is by using the existing keyword 'var'. Eg:
>
>      var $foo = 'bar';
> or
>      var $foo;
>
> If 'var' is seen in a module, then use of any variables below MUST be for
> variables that have been declared.
>
> OK: that is the general idea, details need working on.
>
>
> Note that the use of 'var' to declare variables is OPTIONAL, only use it if you
> want to.
>

I somewhat like this idea, it reminds me of ECMAScript 5's "use strict", 
which I find an invaluable debugging aid and use for all my JavaScript 
programs. Being able to have a *strictly* optional feature defined in 
source, not in the INI, would be wonderful. People who want a notice can 
have it, but myself, I'd like my program to terminate with an error 
message when I use a variable I haven't defined yet, if it's a strict 
mode source file.

Adding a strict mode would allow us to change other things without 
breaking BC, too, though I'm not sure what at present.
-- 
Andrea Faulds
http://ajf.me/