Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44773
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain prohost.org from 209.85.219.213 cause and error)
Cc: Christian Schneider <cschneid@cschneid.com>,
 PHP internals <internals@lists.php.net>
Message-ID: <4637B35E-96A2-46AB-AEEB-DE698B9180C3@prohost.org>
To: Greg Beaver <greg@chiaraquartet.net>
In-Reply-To: <4A536183.407@chiaraquartet.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Tue, 7 Jul 2009 11:14:15 -0400
References: <2D0F5226-EBCA-4B45-BF01-8ED1C643976C@prohost.org> <4A535468.2000606@chiaraquartet.net> <A4DD837EEB0441B1932380ABE8AE8146@pc> <4A535BEF.8060302@cschneid.com> <4A536183.407@chiaraquartet.net>
Subject: Re: [PHP-DEV] Re: Type hinting/casting request for vote
From: ilia@prohost.org (Ilia Alshanetsky)

Greg,

the T_CLASS fix you've suggested in your e-mail to me could work, but  
calling a type hint "class" rather then "object" seems a little  
awkward to me. Plus to your point and earlier Stas' e-mail the patch  
would reserve the a whole bunch of type based keywords, personally I  
feel that this is fine, because its seems wrong to call classes by  
type names, but recognize a fair number of people maybe doing it.

I'll take a look at the lexer, but I am not sure there is a simple  
solution around that.


On 7-Jul-09, at 10:53 AM, Greg Beaver wrote:

> Christian Schneider wrote:
>> Stan Vassilev wrote:
>>>> +1 if the object type hint is change to use T_CLASS so we don't  
>>>> break
>>>> every external package using "Object" as a base class.
>>>> http://www.google.com/codesearch?as_q=class\s%2Bobject&btnG=Search 
>>>> + 
>>>> Code 
>>>> &hl 
>>>> = 
>>>> en 
>>>> &as_lang 
>>>> = 
>>>> php 
>>>> &as_license_restrict 
>>>> =i&as_license=&as_package=&as_filename=&as_case=
>>> Or this can wait until 6.0, when (as I hear) we'll have case- 
>>> sensitive
>>> class names, so Object/object, Int/int won't cause collisions.
>>
>> This won't help much because of functions:
>
> This changes my vote to -1 in any version without a technical fix in  
> the
> patch to avoid this problem.
>
> There are 2 ways to avoid this problem
>
> 1) create a patch allowing reserved words as function/class names.   
> I've
> already tried this for a previous reason, and it's difficult to do
> without vastly over-complicating the lexer.
>
> 2) have 1 syntax, T_*_CAST as in function ((int) $a) {} and have that
> mean strict type hinting.
>
> Ilia: if you can include a lexer patch that allows reserved words in  
> key
> places, I'd be willing to modify my vote.  The problem is supporting
> static class things requires lookahead tokens, thus one would need to
> specify that this pseudo-regex is a T_STRING:
>
> /(LABEL)(?:\s*->|::)/
>
> not to mention having a new "looking for label" state that is entered
> whenever we encounter class|interface\s+(extends|implements|{) or  
> T_NEW
>
> Although having this freedom would be nice, I prefer #2, it's a whole
> lot simpler.
>
> Greg
>
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>