[PHP-DEV] Re: Type hinting/casting request for vote
Ilia Alshanetsky wrote: Last week or so there was a fairly detailed discussion on the internals list regarding type hinting based on my original patch. Since then the patch has been revised to address the major concerns that were identified (breakage of binary compatibility) as well extended with additional functionality (object hint, type casting, reflection support, etc...). The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. Ilia -1. we should not add an syntax into a stable release. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Type hinting/casting request for vote
+1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Type hinting/casting request for vote
Greg Beaver wrote: I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. +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. -1 because of the new keywords bool, boolean, string, binary, unicode, int, integer, long, real, double, float, resource, numeric, scalar, object which cannot be used as function or class names any more (major BC break). I have more comments but they are minor so I restrict myself to this big one... Cheers, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Type hinting/casting request for vote
Ilia Alshanetsky wrote: Last week or so there was a fairly detailed discussion on the internals list regarding type hinting based on my original patch. Since then the patch has been revised to address the major concerns that were identified (breakage of binary compatibility) as well extended with additional functionality (object hint, type casting, reflection support, etc...). The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. +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%2BobjectbtnG=Search+Codehl=enas_lang=phpas_license_restrict=ias_license=as_package=as_filename=as_case= Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Type hinting/casting request for vote
Ilia Alshanetsky wrote: Last week or so there was a fairly detailed discussion on the internals list regarding type hinting based on my original patch. Since then the patch has been revised to address the major concerns that were identified (breakage of binary compatibility) as well extended with additional functionality (object hint, type casting, reflection support, etc...). The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. Ilia +1 with the same caveat as Greg (please object not Object) Thanks, Elizabeth -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hinting/casting request for vote
+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%2BobjectbtnG=Search+Codehl=enas_lang=phpas_license_restrict=ias_license=as_package=as_filename=as_case= Greg 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. I'm really puzzled why a non-essential, and for the past months (years?) controversial and always rejected feature such as strict type hints, has everyone turning 180 degrees and putting it in a minor release in the course of a week. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hinting/casting request for vote
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%2BobjectbtnG=Search+Codehl=enas_lang=phpas_license_restrict=ias_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: http://www.google.com/codesearch?hl=enstart=10sa=Nq=function\s%2B(bool|boolean|string|binary|unicode|int|integer|long|real|double|float|resource|numeric|scalar|object)\s*\(+lang:php Cheers, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hinting/casting request for vote
On Tue, Jul 7, 2009 at 3:15 PM, Stan Vassilevsv_for...@fmethod.com wrote: I'm really puzzled why a non-essential, and for the past months (years?) controversial and always rejected feature such as strict type hints, has everyone turning 180 degrees and putting it in a minor release in the course of a week. Because nearly everyone wants it, and people think it might actually get in this time. It was never rejected, people simply couldnt agree on what it was they wanted, so it never got in. Nearly there, though... Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hinting/casting request for vote
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%2BobjectbtnG=Search+Codehl=enas_lang=phpas_license_restrict=ias_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
Re: [PHP-DEV] Re: Type hinting/casting request for vote
On 07.07.2009, at 16:15, 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%2BobjectbtnG=Search + Code hl = en as_lang = php as_license_restrict=ias_license=as_package=as_filename=as_case= Greg 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. I'm really puzzled why a non-essential, and for the past months (years?) controversial and always rejected feature such as strict type hints, has everyone turning 180 degrees and putting it in a minor release in the course of a week. amen to that. regards Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hinting/casting request for vote
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%2BobjectbtnG=Search
+
Code
hl
=
en
as_lang
=
php
as_license_restrict
=ias_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
Re: [PHP-DEV] Re: Type hinting/casting request for vote
On Tue, Jul 7, 2009 at 3:53 PM, Greg Beaverg...@chiaraquartet.net wrote:
2) have 1 syntax, T_*_CAST as in function ((int) $a) {} and have that
mean strict type hinting.
I dont think this is a good option. Having features dictated by trying
to keep the lexer/parser clean is a bad idea. If the lexer cannot be
fixed, I think the better option is to ruin things for people calling
things Bool, rather than compromising the feature. (I am assuming that
people are still able to call things \mynamespace\bool -- if not, that
changes things).
Thanks,
Paul
--
Paul Biggar
paul.big...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Type hinting/casting request for vote
Ilia Alshanetsky wrote: Last week or so there was a fairly detailed discussion on the internals list regarding type hinting based on my original patch. Since then the patch has been revised to address the major concerns that were identified (breakage of binary compatibility) as well extended with additional functionality (object hint, type casting, reflection support, etc...). The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. Ilia +1 As for when, I'd say it should wait for the next major release, 5.4 or 6.0. But then again, I don't want to wait several years for a feature being discussed now, so I'll go with 5.3.x. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Type hinting/casting request for vote
+1 2009/7/7 Ryan Panning rpann...@gmail.com Ilia Alshanetsky wrote: Last week or so there was a fairly detailed discussion on the internals list regarding type hinting based on my original patch. Since then the patch has been revised to address the major concerns that were identified (breakage of binary compatibility) as well extended with additional functionality (object hint, type casting, reflection support, etc...). The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. Ilia +1 As for when, I'd say it should wait for the next major release, 5.4 or 6.0. But then again, I don't want to wait several years for a feature being discussed now, so I'll go with 5.3.x. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Jarismar C. Silva jarismar@gmail.com
Re: [PHP-DEV] Re: Type hinting/casting request for vote
+1 -- Marcelo Araujo
[PHP-DEV] Re: Type hinting/casting request for vote
-1 for 5.3.x . We should not add major language features at that stage. On 2009-07-07, Ilia Alshanetsky i...@prohost.org wrote: Last week or so there was a fairly detailed discussion on the internals list regarding type hinting based on my original patch. Since then the patch has been revised to address the major concerns that were identified (breakage of binary compatibility) as well extended with additional functionality (object hint, type casting, reflection support, etc...). The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). To keep the process simple flamewar free, please restrict yourself to +/- (1/0), next week monday I'll run a tally of the votes and based on the result we can determine how to proceed further. Ilia -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
