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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
