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
2009/7/6 Ilia Alshanetsky ilia@prohost.org:
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
--
Regards,
Felipe Pena
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.bz2I 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
+1
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.bz2I 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
--
--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9215-8480
MSN: guilhermeblanco@hotmail.com
URL: http://blog.bisna.com
São Paulo - SP/Brazil
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
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.bz2I 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
--
Alexey Zakhlestin
http://www.milkfarmsoft.com/
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...).
+1
Regards,
Matthew
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.bz2I 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
Ilia Alshanetsky schrieb:
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.
I have tested the patch (ran the supplied test suite, reviewed the test
suite) and ran into no issues.
+1
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Sebastian Bergmann schrieb:
+1
Just to be clear, my vote was for putting this into (PHP_5_3) + 1, not
into PHP 5.3.1.
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
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.bz2I 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
Derick
--
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
twitter: @derickr
+1
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.bz2I 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
Obviously, that was not for putting it in PHP 5.3, but in HEAD only.
regards,
Derick
--
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
twitter: @derickr
+1
Ilia Alshanetsky 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
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
+1
-Hannes
that vote is for anything coming after 5.3.x (be 5.4 or 6.x), did not
see the 5.3 only requirement (which makes no sense).
I'm generally -1 on any major change for 5.3.x.
+1
--
Pierre
--
Pierre
+1
--
Slan,
David
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
+1
2009/7/7 Ilia Alshanetsky ilia@prohost.org:
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.bz2I 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
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
I need a car : http://snipurl.com/l4pih
ZOPA : http://uk.zopa.com/member/RQuadling
+1
Rafael Dohms
On Tue, Jul 7, 2009 at 9:44 AM, Richard Quadling
rquadling@googlemail.comwrote:
2009/7/7 Ilia Alshanetsky ilia@prohost.org:
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.bz2I 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
--
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
I need a car : http://snipurl.com/l4pih
ZOPA : http://uk.zopa.com/member/RQuadling
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.bz2I 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.
Greg
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_CLASSso 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
+1 if the object type hint is change to use
T_CLASSso we don't break
every external package using "Object" as a base class.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
Stan Vassilev wrote:
+1 if the object type hint is change to use
T_CLASSso we don't break
every external package using "Object" as a base class.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.
Hi,
To clarify, my vote was for 6.0.0, I did not catch the "put in 5.3" part
of Ilia's original email.
Greg
Stan Vassilev wrote:
+1 if the object type hint is change to use
T_CLASSso 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:
http://www.google.com/codesearch?hl=en&start=10&sa=N&q=function\s%2B(bool|boolean|string|binary|unicode|int|integer|long|real|double|float|resource|numeric|scalar|object)\s*(+lang:php
Cheers,
- Chris
Christian Schneider wrote:
Stan Vassilev wrote:
+1 if the object type hint is change to use
T_CLASSso 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
-
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. -
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
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.
Christian Schneider wrote:
Stan Vassilev wrote:
+1 if the object type hint is change to use
T_CLASSso 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
&hlen
&as_langphp
&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
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.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_NEWAlthough having this freedom would be nice, I prefer #2, it's a whole
lot simpler.Greg
- 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.biggar@gmail.com
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.biggar@gmail.com
+1 if the object type hint is change to use
T_CLASSso 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
&hlen
&as_langphp
&as_license_restrict=i&as_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
mls@pooteeweet.org
+1 from me
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.bz2I 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
Ilia Alshanetsky 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).
+1
[..]
- Mark
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.bz2I 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
2009/7/7 Ilia Alshanetsky ilia@prohost.org:
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...).
+1
--
regrads,
Kalle Sommer Nielsen
kalle@php.net
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).
I don't want to start a long discussion, but IMO this and other major
language changes doen't belong in a point release of 5.3.x (whether
it's 5.3.2 or 5.3.192).
so:
-1 in 5.3
-1 throw away
+1 in HEAD (or 5.4; sorry for opening $canOfWorms)
S
-1 for 5.x
+1 for 6.0
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.
I'm struggling here but must emit -1 because PHP does not add features
within point (5.3.x) releases, especially those affecting syntax like
this. But if this philosophy changes, then also add traits. :)
Regards,
Philip
+1
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.bz2I 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
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.bz2I 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.
-a
Andrei Zmievski 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.
Sorry, I should have read better. My +1 was for the feature in general, not for 5.3. I
think we should concentrate most of the new feature development on 6.0, now that 5.3 is
out to avoid having yet another "feature-filled" 5.x release.
So, once again, completely against this going into 5.3.
-Andrei
Andrei Zmievski 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.
Sorry, I should have read better. My +1 was for the feature in general,
not for 5.3. I think we should concentrate most of the new feature
development on 6.0, now that 5.3 is out to avoid having yet another
"feature-filled" 5.x release.So, once again, completely against this going into 5.3.
+1 for what Andrei said ( to further muddy the waters ). Ilia, why 5.3
or die? This feature should be in HEAD IMO.
Aside: I'm personally really excited at the possibilities of improving
completion in Komodo for code that uses this feature.
Jeff
Andrei Zmievski 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.
Sorry, I should have read better. My +1 was for the feature in
general,
not for 5.3. I think we should concentrate most of the new feature
development on 6.0, now that 5.3 is out to avoid having yet another
"feature-filled" 5.x release.So, once again, completely against this going into 5.3.
+1 for what Andrei said ( to further muddy the waters ). Ilia, why
5.3 or die? This feature should be in HEAD IMO.
PHP 6 is too far off in a practical sense (sorry Andrei) from the time
where I can see myself using it in production or other people
benefiting from this function. The (simpler) variant of provided patch
is what is currently being used on production, if it can go into 5.3,
which I see myself using soon, then there is a tangible benefit from
making this a public feature (reduce the amount of custom patching)
and spending the time to refine it for public consumption and making
it PHP 6 ready. If it can only be added in PHP6, then the amount of
interest I personally have towards further evolution of this feature
is very minimal.
So for me personally, the practically of the feature's deployment is
critical.
Ilia Alshanetsky wrote:
PHP 6 is too far off in a practical sense (sorry Andrei) from the time
where I can see myself using it in production or other people benefiting
from this function. The (simpler) variant of provided patch is what is
currently being used on production, if it can go into 5.3, which I see
myself using soon, then there is a tangible benefit from making this a
public feature (reduce the amount of custom patching) and spending the
time to refine it for public consumption and making it PHP 6 ready. If
it can only be added in PHP6, then the amount of interest I personally
have towards further evolution of this feature is very minimal.So for me personally, the practically of the feature's deployment is
critical.
Ilia, I understand what you're saying, but with this kind of attitude PHP 6 might never
arrive if we all keep putting only the things that are practical for our (personal) usage
into 5.3, 5.4, etc. The best way to shorten the time horizon of 6 is to treat it as the
primary target of the development effort.
-Andrei
Andrei,
PHP represents a major change on every aspect of the language, I think
you gotta appreciate it that even if it were to be released today
there would be sometime before it can certified as production ready in
terms of stability and performance. I'd go on a limb and say that PHP6
is probably 3-4 years away from being production material and that's
assuming it gets released in the next 8-12 months. During that time
people still need to develop applications, which are getting
increasingly complex and any helpful tool/feature would be an asset.
Ilia Alshanetsky wrote:
PHP 6 is too far off in a practical sense (sorry Andrei) from the
time where I can see myself using it in production or other people
benefiting from this function. The (simpler) variant of provided
patch is what is currently being used on production, if it can go
into 5.3, which I see myself using soon, then there is a tangible
benefit from making this a public feature (reduce the amount of
custom patching) and spending the time to refine it for public
consumption and making it PHP 6 ready. If it can only be added in
PHP6, then the amount of interest I personally have towards further
evolution of this feature is very minimal.
So for me personally, the practically of the feature's deployment
is critical.Ilia, I understand what you're saying, but with this kind of
attitude PHP 6 might never arrive if we all keep putting only the
things that are practical for our (personal) usage into 5.3, 5.4,
etc. The best way to shorten the time horizon of 6 is to treat it as
the primary target of the development effort.-Andrei
-1
However, this is ONLY because I do not feel PHP 5.3 is the place to put
this. However, I do have to agree with Ilia here that PHP 6 is too far away
and it would be nice to have this feature long before then. I would however,
be very for adding something similar to this patch in a PHP 5.4 release. I
don't see why a PHP 5.4 release can't be done relativly quickly (Like 6-12
months) by just making it more of a minor internal update but something that
could have large impacts on user code (syntax changes for type hints).
I'd like to see a feature like this out as soon as possible so that people
can start adopting it.
- Graham Kelly
Andrei,
PHP represents a major change on every aspect of the language, I think you
gotta appreciate it that even if it were to be released today there would be
sometime before it can certified as production ready in terms of stability
and performance. I'd go on a limb and say that PHP6 is probably 3-4 years
away from being production material and that's assuming it gets released in
the next 8-12 months. During that time people still need to develop
applications, which are getting increasingly complex and any helpful
tool/feature would be an asset.Ilia Alshanetsky wrote:
PHP 6 is too far off in a practical sense (sorry Andrei) from the time
where I can see myself using it in production or other people benefiting
from this function. The (simpler) variant of provided patch is what is
currently being used on production, if it can go into 5.3, which I see
myself using soon, then there is a tangible benefit from making this a
public feature (reduce the amount of custom patching) and spending the time
to refine it for public consumption and making it PHP 6 ready. If it can
only be added in PHP6, then the amount of interest I personally have towards
further evolution of this feature is very minimal.
So for me personally, the practically of the feature's deployment is
critical.Ilia, I understand what you're saying, but with this kind of attitude PHP
6 might never arrive if we all keep putting only the things that are
practical for our (personal) usage into 5.3, 5.4, etc. The best way to
shorten the time horizon of 6 is to treat it as the primary target of the
development effort.-Andrei
However, this is ONLY because I do not feel PHP 5.3 is the place to put
this. However, I do have to agree with Ilia here that PHP 6 is too far away
and it would be nice to have this feature long before then. I would however,
be very for adding something similar to this patch in a PHP 5.4 release. I
don't see why a PHP 5.4 release can't be done relativly quickly (Like 6-12
months) by just making it more of a minor internal update but something that
could have large impacts on user code (syntax changes for type hints).
With this logic, we got a PHP 5.3 as well, and with the same logic there
will be a PHP 5.4, 5.5, 5.6 and we never get to 6. Instead of putting
stuff in PHP 5.4 (which at the moment is not planned), why not focus
all effort on 6 to make sure it comes out faster? And although this
feature is useful, it's not something that I
would really-need-right-now.
regards,
Derick
--
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
twitter: @derickr
Derick Rethans wrote:
However, this is ONLY because I do not feel PHP 5.3 is the place to put
this. However, I do have to agree with Ilia here that PHP 6 is too far away
and it would be nice to have this feature long before then. I would however,
be very for adding something similar to this patch in a PHP 5.4 release. I
don't see why a PHP 5.4 release can't be done relativly quickly (Like 6-12
months) by just making it more of a minor internal update but something that
could have large impacts on user code (syntax changes for type hints).With this logic, we got a PHP 5.3 as well, and with the same logic there
will be a PHP 5.4, 5.5, 5.6 and we never get to 6. Instead of putting
stuff in PHP 5.4 (which at the moment is not planned), why not focus
all effort on 6 to make sure it comes out faster? And although this
feature is useful, it's not something that I would really-need-right-now.
Yes please to PHP6!
Although I suspect there is still a debate on retaining PHP5.x as being
'ascii native' and PHP6 being 'unicode native' so new features end up
having to be 'back ported'?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Derick Rethans wrote:
However, this is ONLY because I do not feel PHP 5.3 is the place to put
this. However, I do have to agree with Ilia here that PHP 6 is too far away
and it would be nice to have this feature long before then. I would however,
be very for adding something similar to this patch in a PHP 5.4 release. I
don't see why a PHP 5.4 release can't be done relativly quickly (Like 6-12
months) by just making it more of a minor internal update but something that
could have large impacts on user code (syntax changes for type hints).With this logic, we got a PHP 5.3 as well, and with the same logic there
will be a PHP 5.4, 5.5, 5.6 and we never get to 6. Instead of putting
stuff in PHP 5.4 (which at the moment is not planned), why not focus
all effort on 6 to make sure it comes out faster? And although this
feature is useful, it's not something that I
would really-need-right-now.regards,
Derick
Agree 100%
+1 for parameter type enforcement in PHP 6
Steven
Hi.
Derick Rethans wrote:
With this logic, we got a PHP 5.3 as well, and with the same logic
there will be a PHP 5.4, 5.5, 5.6 and we never get to 6. Instead of
putting stuff in PHP 5.4 (which at the moment is not planned), why
not focus all effort on 6 to make sure it comes out faster? And
although this feature is useful, it's not something that I would
really-need-right-now.regards,
DerickAgree 100%
+1 for parameter type enforcement in PHP 6
+1 to that.
Regards,
Karsten
Hi,
I am -1 on the inclusion of cast support. IMHO this part isnt thought
out and was just thrown in to silence those who feel that there is a
use case for non strict type hinting. But in that case I might as well
leave the type cast in the API calling code. The number of characters
saved are next to nothing, the performance impact is probably also
fairly irrelevant and with this syntax I get slapped and then I can
choose if I want to cast manually or do something else. But just
hiding things by just blindly casting seems counter productive (which
is why I proposed to add reasonable checks before doing the cast in my
RFC that would make things more compatible with data coming out of a
database, config file or other trusted data source). I just do not see
what is gained at all from:
A) foo((int)$bar);
function bar(int $bar) {}
vs.
B) foo($bar);
function bar((int) $bar) {}
What am I really saying with B)?
I don't care what you give me, I am going to use it as an int anyways?
IMHO no need to introduce a special syntax for this.
Of course I am also quite opposed to sticking this into 5.3.
Finally I would like to ask to rename this entire feature (including
what we currently already have) to "type checking" or something other
than "hint" in the documentation.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
B) foo($bar);
function bar((int) $bar) {}What am I really saying with B)?
I don't care what you give me, I am going to use it as an int anyways?
Exactly. Very simple. I would phrase it as "I'll accept anything and
cast it to an int".
Of course I am also quite opposed to sticking this into 5.3.
On which grounds? If you don't like the feature, please cast a -1
vote. If its because of the BC problems, I believe you and Johannes
have veto power on what goes into 5.3.x? If so, do you intend to use
it?
Finally I would like to ask to rename this entire feature (including what we
currently already have) to "type checking" or something other than "hint" in
the documentation.
Seconded.
Thanks,
Paul
--
Paul Biggar
paul.biggar@gmail.com
Of course I am also quite opposed to sticking this into 5.3.
On which grounds? If you don't like the feature, please cast a -1
That adding language syntax sugar anything but a major or minor
release is a bad idea.
And this even if Ilia does manage to solve the BC issues. If there are
BC issues, we shouldnt even have to talk about 5.3 for one second.
vote. If its because of the BC problems, I believe you and Johannes
have veto power on what goes into 5.3.x? If so, do you intend to use
it?
I dont think we have a veto power, nor would I want to use it if we
did have one. One job is to keep things focused and appeal to the
general sanity if we feel that things are going off track. I would
want to appeal to the general sanity on this one though :)
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Paul Biggar wrote:
B) foo($bar);
function bar((int) $bar) {}What am I really saying with B)?
I don't care what you give me, I am going to use it as an int anyways?Exactly. Very simple. I would phrase it as "I'll accept anything and
cast it to an int".Of course I am also quite opposed to sticking this into 5.3.
On which grounds? If you don't like the feature, please cast a -1
vote. If its because of the BC problems, I believe you and Johannes
have veto power on what goes into 5.3.x? If so, do you intend to use
it?
On the grounds that 5.3.x is now in maintenance mode, no new features.
This is not a new way of conducting business in PHP, FYI.
Greg
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.
Sorry, I should have read better. My +1 was for the feature in
general, not for 5.3. I think we should concentrate most of the new
feature development on 6.0, now that 5.3 is out to avoid having yet
another "feature-filled" 5.x release.So, once again, completely against this going into 5.3.
Same here. +1 for HEAD, -1 for 5.3.
-- Gwynne
+1 for HEAD and 5.3
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.
Sorry, I should have read better. My +1 was for the feature in general,
not for 5.3. I think we should concentrate most of the new feature
development on 6.0, now that 5.3 is out to avoid having yet another
"feature-filled" 5.x release.So, once again, completely against this going into 5.3.
Same here. +1 for HEAD, -1 for 5.3.
-- Gwynne
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.bz2I 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 on 5.3. The window for adding new major features to 5.3 is obviously
long gone. Not sure why you are even suggesting it.
+0 on parts of it for the next major release. You still haven't
convinced me that strict type checking won't cause more problems than it
will solve, but I do see the benefits.
-Rasmus
At 21:38 07/07/2009, Rasmus Lerdorf wrote:
-1 on 5.3. The window for adding new major features to 5.3 is obviously
long gone. Not sure why you are even suggesting it.+0 on parts of it for the next major release. You still haven't
convinced me that strict type checking won't cause more problems than it
will solve, but I do see the benefits.
Agreed 100%:
-1 on 5.3. Such a major change simply does not belong in 5.3 as a
last-minute addition.
+0 for revisiting for the next major release. Will change to +1 if
we focus on conversion only - with slightly stricter semantics than
the ones for internal functions, but with very much the same theme -
as per my email.
Zeev
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.bz2I 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.
+1
2009/7/7 Ryan Panning rpanning@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.bz2I 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.--
--
Jarismar C. Silva
jarismar.php@gmail.com
+1
-- Marcelo Araujo
-1 for 5.3.x . We should not add major language features at that stage.
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.bz2I 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
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
If I read the patch correctly it still breaks binary compatibility:
-#define ZEND_ARG_OBJ_INFO(pass_by_ref, name, classname, allow_null) { #name, sizeof(#name)-1, #classname, sizeof(#classname)-1, 0, allow_null, pass_by_ref, 0, 0 },
-#define ZEND_ARG_ARRAY_INFO(pass_by_ref, name, allow_null) { #name, sizeof(#name)-1, NULL, 0, 1, allow_null, pass_by_ref, 0, 0 },
+#define ZEND_ARG_OBJ_INFO(pass_by_ref, name, classname, allow_null) { #name, sizeof(#name)-1, #classname, sizeof(#classname)-1, IS_CLASS, allow_null, pass_by_ref, 0, 0 },
+#define ZEND_ARG_ARRAY_INFO(pass_by_ref, name, allow_null) { #name, sizeof(#name)-1, NULL, 0, IS_ARRAY, allow_null, pass_by_ref, 0, 0 },
Having an "old" 5.3 extension with a typehint expecting an array
arg_info.array_type_hint will be set to 1.
The newly compiled engine with this patch will then do
-
/* existing type already matches the hint or forced type */ -
if (Z_TYPE_P(arg) == cur_arg_info->array_type_hint || Z_TYPE_P(arg) == (cur_arg_info->array_type_hint ^ (1<<7))) {
as it's main type check, but Z_TYPE_P(arg) will be IS_ARRAY (5) which
doesn't match the 1 provided by the old extension, other checks in there
will fail too, so the valid param will be rejected whereas an integer
(IS_LONG 1) will be accepted where the extension expects an array.
The only clean why I see for doing this is by breaking the binary
compatibility, then one could also rename "array_type_hint" and change
it's type from zend_bool to a better suited type.
Independently from this compatibility issue I'd vote -1 for 5.3.
Yes 5.3 took loooong and we should, in my opinion, try to be faster with
the next "feature release" instead of changing syntax and adding other
big features in bugfix releases.
I know it is bad to wait long till new features become available (btw.
that's one of the reasons why 5.3 took so long - "let's add this feature
else we have to wait so long till we get the next major version") but
adding features and changing syntax is a pain for users and at least one
of the reasons why distributors won't update the PHP versions they are
offering (What's the current PHP version in RedHat, again? - Yes, I know
people should built PHP themselves but still...)
A thing I wish for sometime is a change to our release model but never
sat really down to do the research and write a good proposal. The basic
concept would be to have a pre announced release date (maybe +/- a few
days) and therefore a "last integration date" a few weeks/months
beforehand. Ideally the release and integration date for the next
version would be set before the integration date for the current tree is
reached. After the integration day only be bug fixes should be allowed,
no new features at all. By such a model people can plan and if a feature
doesn't make it into a release it's not rejected for an unforeseeable
future. Similar models, in different flavors, are used by at least
PostgreSQL, Ubuntu, OpenSolaris and quite a few more ... but well,
that's off-topic for this thread and I wanted to do some more research
with other projects before proposing such a thing ....
johannes
2009/7/7 Johannes Schlüter johannes@php.net:
Last week or so there was a fairly detailed discussion on the
internals list regarding type hinting based on my original patch.
Having an "old" 5.3 extension with a typehint expecting an array
arg_info.array_type_hint will be set to 1.
The newly compiled engine with this patch will then do
- /* existing type already matches the hint or forced type */
- if (Z_TYPE_P(arg) == cur_arg_info->array_type_hint || Z_TYPE_P(arg) == (cur_arg_info->array_type_hint ^ (1<<7))) {
as it's main type check, but Z_TYPE_P(arg) will be IS_ARRAY (5) which
doesn't match the 1 provided by the old extension, other checks in there
will fail too, so the valid param will be rejected whereas an integer
(IS_LONG 1) will be accepted where the extension expects an array.
I raised this in my review, to which Ilia replied "It should be fine"
(http://news.php.net/php.internals/44707). I would not have thought it
would be fine.
I had been thinking that Ilia would have to hack it to make 1 mean
array in this case, which would be ugly, but workable. Based on the
arguments in this thread, I believe it shouldn't go into 5.3 at all.
Are we allowed break the ABI for 5.4 (I would think so, but amn't
sure).
Overall, I'm very disappointed with the way this has been conducted.
When reviews were posted they are not replied to (Stas posted
http://news.php.net/php.internals/44710, I posted
http://news.php.net/php.internals/44706, and I dont see any replies
except a cursory response to mine). Furthermore:
- the RFC process has been wilfully ignored (despite multiple requests)
- a vote was asked for when Lukas was still trying to discuss his proposal
- the vote was take it or leave it
- there has been a general attitude of "throwing the toys out of the pram"
I am mostly for the patch, and I 100% support the idea. However, I
feel I have to vote against it, and urge others to do the same, until
the entire mess is rectified.
Ilia, I respect the work you have put into this, but I would ask you
to withdraw the patch and the vote until these things have been sorted
out.
-1
Thanks,
Paul
--
Paul Biggar
paul.biggar@gmail.com
Paul Biggar wrote:
- the RFC process has been wilfully ignored (despite multiple requests)
For me it is pretty hard to take a major feature for 5.3 RFC seriously
when it comes a week after we finally get 5.3 out the door.
-Rasmus
Rasmus,
Well, 5.3 has been in feature lock for quite some time, its not like
its been a week or two since we went from "features in" phase to
"stabilization" phase.
Paul Biggar wrote:
- the RFC process has been wilfully ignored (despite multiple
requests)For me it is pretty hard to take a major feature for 5.3 RFC seriously
when it comes a week after we finally get 5.3 out the door.-Rasmus
That doesn't really change the timing, especially since you said you
have been using it for 2 years. Why pick the week after the 5.3 release
to propose it for 5.3? It makes very little sense to me, and I think
consensus is building that we aren't going to add this to 5.3.
I think half the people who voted +1 didn't realize you were seriously
thinking of pushing it into 5.3
-Rasmus
Ilia Alshanetsky wrote:
Rasmus,
Well, 5.3 has been in feature lock for quite some time, its not like its
been a week or two since we went from "features in" phase to
"stabilization" phase.Paul Biggar wrote:
- the RFC process has been wilfully ignored (despite multiple requests)
For me it is pretty hard to take a major feature for 5.3 RFC seriously
when it comes a week after we finally get 5.3 out the door.-Rasmus
That doesn't really change the timing, especially since you said you
have been using it for 2 years. Why pick the week after the 5.3
release
to propose it for 5.3? It makes very little sense to me, and I think
consensus is building that we aren't going to add this to 5.3.
I wish I had time to post the patch sooner, but timing was such that
it was not an option. Plus people have tried to post the same
functionality before there was patch from Hannes back in 2006, a full
RFC by Fellipe in 2008 (with patch) and now my attempt in 2009. After
some discussions at the developer meeting in Chicago and seeing that
there was a substantial interest in the feature I've cleaned up the
code and posted the patch.
I think half the people who voted +1 didn't realize you were seriously
thinking of pushing it into 5.3
Well, its only Tuesday there is plenty of time for people to change
their mind (like some already have). Agreeably its a major decisions
and I think everyone would agree it should not hinge on 1-2 votes
either way, there has to be a substantial "let it in" consensus for it
to go in.
Ilia
Ilia Alshanetsky wrote:
That doesn't really change the timing, especially since you said you
have been using it for 2 years. Why pick the week after the 5.3 release
to propose it for 5.3? It makes very little sense to me, and I think
consensus is building that we aren't going to add this to 5.3.I wish I had time to post the patch sooner, but timing was such that it
was not an option. Plus people have tried to post the same functionality
before there was patch from Hannes back in 2006, a full RFC by Fellipe
in 2008 (with patch) and now my attempt in 2009. After some discussions
at the developer meeting in Chicago and seeing that there was a
substantial interest in the feature I've cleaned up the code and posted
the patch.I think half the people who voted +1 didn't realize you were seriously
thinking of pushing it into 5.3Well, its only Tuesday there is plenty of time for people to change
their mind (like some already have). Agreeably its a major decisions and
I think everyone would agree it should not hinge on 1-2 votes either
way, there has to be a substantial "let it in" consensus for it to go in.
Like I said earlier on IRC, I'm +1 for this in 5.4 if that ever happens.
Otherwise it's gotta be PHP 6. Or just spork. :)
--Jani
Jani Taskinen wrote:
Ilia Alshanetsky wrote:
That doesn't really change the timing, especially since you said you
have been using it for 2 years. Why pick the week after the 5.3 release
to propose it for 5.3? It makes very little sense to me, and I think
consensus is building that we aren't going to add this to 5.3.I wish I had time to post the patch sooner, but timing was such that
it was not an option. Plus people have tried to post the same
functionality before there was patch from Hannes back in 2006, a full
RFC by Fellipe in 2008 (with patch) and now my attempt in 2009. After
some discussions at the developer meeting in Chicago and seeing that
there was a substantial interest in the feature I've cleaned up the
code and posted the patch.I think half the people who voted +1 didn't realize you were seriously
thinking of pushing it into 5.3Well, its only Tuesday there is plenty of time for people to change
their mind (like some already have). Agreeably its a major decisions
and I think everyone would agree it should not hinge on 1-2 votes
either way, there has to be a substantial "let it in" consensus for it
to go in.Like I said earlier on IRC, I'm +1 for this in 5.4 if that ever happens.
Otherwise it's gotta be PHP 6. Or just spork. :)--Jani
One more thing: It seems there is no reason not to simply commit it to
HEAD. That's the development branch, if the thing isn't good, it can be
removed / modified / etc. This voting is really whether it should be
merged or not..
--Jani
Hi!
One more thing: It seems there is no reason not to simply commit it to
HEAD. That's the development branch, if the thing isn't good, it can be
Erm, I was under impression that development branch is for developing
new functionalities which were agreed on, not for committing any code
that anybody wanted to without any consensus or agreement on what should
happen with it. So yes, there's a reason not to "simply commit" this or
any other major language-level functionality without prior discussion.
The fact that you can remove it doesn't mean you should commit first and
discuss later.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
One more thing: It seems there is no reason not to simply commit it to
HEAD. That's the development branch, if the thing isn't good, it can beErm, I was under impression that development branch is for developing new
functionalities which were agreed on, not for committing any code that
anybody wanted to without any consensus or agreement on what should happen
with it. So yes, there's a reason not to "simply commit" this or any other
major language-level functionality without prior discussion. The fact that
you can remove it doesn't mean you should commit first and discuss later.
As I agree with that statement, we have to accept that we have a
consensus about this addition. For what I can read the implementation
is almost complete, there are issues but they can be fixed afterward
as well as all the other side effects we are going to have, no?
Cheers,
Pierre
Since the votes seem to switch to 6.0 instead of 5.3, would it be
feasible to throw an E_DEPRECATED in 5.3.1 if one declares a
function/class called int/bool/object/whatever ?
Just throwing the idea in the wild since I am not able to assess if
that's doable, but it might be a good idea to add it as soon as
possible if it is, especially if we want to skip a 5.4
Cheers,
Jordi
All of the identified issues can be resolved and none of them
represent a major challenge to address. However, if there is no
consensus to put this in the near future (which at this point is 5.3),
I have hard time justifying spending further time on this. The
original patch that was posted, that did break BC was far simpler and
featureless, the changes since (which took a fair amount of work) were
specifically made to address some of the main concerns that were on
the list. I feel what is on the table right now is pretty close to
what a final product could be, to have a vote on it. If decision is
made to proceed within a practical release schedule, then suffice to
say that I'd be more then happy to put further time to address the
minor issues indicated.
2009/7/7 Johannes Schlüter johannes@php.net:
Last week or so there was a fairly detailed discussion on the
internals list regarding type hinting based on my original patch.Having an "old" 5.3 extension with a typehint expecting an array
arg_info.array_type_hint will be set to 1.
The newly compiled engine with this patch will then do
/* existing type already matches the hint or forcedtype */
if (Z_TYPE_P(arg) == cur_arg_info->array_type_hint|| Z_TYPE_P(arg) == (cur_arg_info->array_type_hint ^ (1<<7))) {
as it's main type check, but Z_TYPE_P(arg) will be IS_ARRAY (5) which
doesn't match the 1 provided by the old extension, other checks in
there
will fail too, so the valid param will be rejected whereas an integer
(IS_LONG 1) will be accepted where the extension expects an array.I raised this in my review, to which Ilia replied "It should be fine"
(http://news.php.net/php.internals/44707). I would not have thought it
would be fine.I had been thinking that Ilia would have to hack it to make 1 mean
array in this case, which would be ugly, but workable. Based on the
arguments in this thread, I believe it shouldn't go into 5.3 at all.
Are we allowed break the ABI for 5.4 (I would think so, but amn't
sure).Overall, I'm very disappointed with the way this has been conducted.
When reviews were posted they are not replied to (Stas posted
http://news.php.net/php.internals/44710, I posted
http://news.php.net/php.internals/44706, and I dont see any replies
except a cursory response to mine). Furthermore:
- the RFC process has been wilfully ignored (despite multiple
requests)- a vote was asked for when Lukas was still trying to discuss his
proposal- the vote was take it or leave it
- there has been a general attitude of "throwing the toys out of
the pram"I am mostly for the patch, and I 100% support the idea. However, I
feel I have to vote against it, and urge others to do the same, until
the entire mess is rectified.Ilia, I respect the work you have put into this, but I would ask you
to withdraw the patch and the vote until these things have been sorted
out.-1
Thanks,
Paul--
Paul Biggar
paul.biggar@gmail.com
2009/7/8 Ilia Alshanetsky ilia@prohost.org:
All of the identified issues can be resolved and none of them represent a
major challenge to address. However, if there is no consensus to put this in
OK, but you had not said you would resolve them. I would appreciate
some detail on what you will do to address them.
the near future (which at this point is 5.3), I have hard time justifying
spending further time on this. The original patch that was posted, that did
break BC was far simpler and featureless, the changes since (which took a
fair amount of work) were specifically made to address some of the main
concerns that were on the list. I feel what is on the table right now is
pretty close to what a final product could be, to have a vote on it. If
Personally, I had gotten the impression that this was the final
product, and that we could take it or leave it.
decision is made to proceed within a practical release schedule, then
suffice to say that I'd be more then happy to put further time to address
the minor issues indicated.
I recommend:
- stop the vote
- address the issues (possibly deferring them until after voting, or whatever)
- write an RFC
- wait for Lukas to finish what he's doing
- new vote, more options (5.3.x/5.4/6.0, Lukas'/yours, make it clear
what we're voting for)
Thanks,
Paul
2009/7/7 Johannes Schlüter johannes@php.net:
Last week or so there was a fairly detailed discussion on the
internals list regarding type hinting based on my original patch.Having an "old" 5.3 extension with a typehint expecting an array
arg_info.array_type_hint will be set to 1.
The newly compiled engine with this patch will then do
- /* existing type already matches the hint or forced type
*/- if (Z_TYPE_P(arg) == cur_arg_info->array_type_hint ||
Z_TYPE_P(arg) == (cur_arg_info->array_type_hint ^ (1<<7))) {as it's main type check, but Z_TYPE_P(arg) will be IS_ARRAY (5) which
doesn't match the 1 provided by the old extension, other checks in there
will fail too, so the valid param will be rejected whereas an integer
(IS_LONG 1) will be accepted where the extension expects an array.I raised this in my review, to which Ilia replied "It should be fine"
(http://news.php.net/php.internals/44707). I would not have thought it
would be fine.I had been thinking that Ilia would have to hack it to make 1 mean
array in this case, which would be ugly, but workable. Based on the
arguments in this thread, I believe it shouldn't go into 5.3 at all.
Are we allowed break the ABI for 5.4 (I would think so, but amn't
sure).Overall, I'm very disappointed with the way this has been conducted.
When reviews were posted they are not replied to (Stas posted
http://news.php.net/php.internals/44710, I posted
http://news.php.net/php.internals/44706, and I dont see any replies
except a cursory response to mine). Furthermore:
- the RFC process has been wilfully ignored (despite multiple requests)
- a vote was asked for when Lukas was still trying to discuss his
proposal
- the vote was take it or leave it
- there has been a general attitude of "throwing the toys out of the
pram"I am mostly for the patch, and I 100% support the idea. However, I
feel I have to vote against it, and urge others to do the same, until
the entire mess is rectified.Ilia, I respect the work you have put into this, but I would ask you
to withdraw the patch and the vote until these things have been sorted
out.-1
Thanks,
Paul--
Paul Biggar
paul.biggar@gmail.com
--
Paul Biggar
paul.biggar@gmail.com
- wait for Lukas to finish what he's doing
- new vote, more options (5.3.x/5.4/6.0, Lukas'/yours, make it clear
what we're voting for)
Do not wait for me. I have decided it doesn't make sense for me to
write this RFC. There was essentially nobody that even agreed with the
basic principle and I do not think I have what it takes to convince
people otherwise. I would very much appreciate it if someone who has
just been lurking for now, to pick up my RFC and improve it so that
people do understand what I was trying to say.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.bz2I 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 (5.4/6.0 and "object")
Tobias Schlitt tobias@schlitt.info GPG Key: 0xC462BC14
a passion for php http://schlitt.info/opensource
Member of the eZ Components project http://components.ez.no
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkpT6CEACgkQ5bO3TcRivBSHDACgu9ymI+3eDhyZozd+cn9f+cBi
GIcAoLRK13NOZaSlQuKyMxl9Zu8TW16r
=CCc0
-----END PGP SIGNATURE
-1 for 5.x
+1 for 6.0
Otherwise the Perl 6 guys will starting making their own jokes about
being released before PHP 6.
--Wez.
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.
Aside: I'd like to propose an internals-specific mutation of Godwin's
law, which might state:
"As a PHP internals discussion thread grows longer, the probability of a
comparison involving Perl 6 approaches 1."
JG
-1 for 5.x
+1 for 6.0Otherwise the Perl 6 guys will starting making their own jokes about
being released before PHP 6.--Wez.
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.
--
blog: http://www.openkomodo.com/blogs/jeffg
web: http://www.ActiveState.com
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.bz2I 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
--
Regards,
Wang Yi
-1 for 5.3
0 for 5.x (if there ever will be one)
+1 for 6.0
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.bz2I 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
--
Liip AG // Feldstrasse 133 // CH-8004 Zurich
Tel +41 43 500 39 81 // Mobile +41 76 561 88 60
www.liip.ch // blog.liip.ch // GnuPG 0x5CE1DECB
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.bz2I 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.
Ilia Alshanetsky wrote:
<div class="moz-text-flowed" style="font-family: -moz-fixed">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.bz2I 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
</div>
-1 for PHP 5.3
0 for type casting
+1 for type enforcing a la "function a(int $param)"
Steven
-
The patch introduce several new reserved words (resource, numeric,
scalar, object). This may break existing applications which use these
names as function or class names. -
The patch should define something like ZEND_ARG_TYPE_INFO()
-
do we really need IS_CLASS constant?
-
arg_info->array_type_hint should be probably changed into
arg_info->type_hint. May be it's better to use bitset mask for it.
Then we won't need IS_SCALAR and IS_NUMERIC as well and
arg_info->allow_null field.
Otherwise the patch looks good, but note that for now it only slowdowns
execution a bit because of addition checks. I hope, it'll be possible to
use these hints in the future to generate more optimal code.
+1 for php6 after improvements
Thanks. Dmitry.
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.bz2I 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
- The patch should define something like ZEND_ARG_TYPE_INFO()
Yeah, that can be used or existing macros can be retained using "type"
parameter, which can even made BC compliant by using new sets of
constants that match the IS_ARRAY or "not hint" semantics.
- do we really need IS_CLASS constant?
Only because there is a class hint (currently supported) function foo
(StdClass $foo) {} and there was a request to support a generic object
hint. So one became IS_CLASS and one is IS_OBJECT.
- arg_info->array_type_hint should be probably changed into
arg_info->type_hint. May be it's better to use bitset mask for it.
Then we won't need IS_SCALAR and IS_NUMERIC as well and arg_info-allow_null field.
Originally that is how I had it, but to avoid BC break I've renamed
the property back to type_hint.
Otherwise the patch looks good, but note that for now it only
slowdowns execution a bit because of addition checks. I hope, it'll
be possible to use these hints in the future to generate more
optimal code.+1 for php6 after improvements
Thanks. Dmitry.
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
Hi!
Only because there is a class hint (currently supported) function foo
(StdClass $foo) {} and there was a request to support a generic object
hint. So one became IS_CLASS and one is IS_OBJECT.
I'd say IS_OBJECT can fit both - we could treat empty class name as "any
object".
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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.bz2I 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
(subject to release master veto)
And I doubt that my vote counts anyway...
This seems simple enough to grok, and seems to make the type-hinter
crowd happy, except for the name "hint"
--
Some people ask for gifts here.
I just want you to buy an Indie CD for yourself:
http://cdbaby.com/search/from/lynch
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
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.bz2I 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
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.bz2I 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
Hi List,
I've been watching this thread silently and reply now just to let you
all know how i, as a php developer (as in writing php scripts), would
like to see this feature to get in php.
I personally would be highly in favor of adding type hinting/casting
BUT with the benifit that php actually becomes faster if you do things
like that. Afterall you can use way more effective c code if you know
what you expect right? As for the version to include type
hinting/casting. I would say as soon as possible but i also see a big
issue comming up if it's added in, lets say, 5.3.1 or 5.3.2... it
makes no sence that a major php version that got released just over a
week ago (5.3) doesn't have a big feature like this and a minor
version would include it.. That's somewhat odd. I would say: make a
php version between 5.3 and 6.0 that introduces syntax changes and
make that version (in terms of syntax) backwards (5.3) and forward
(6.0) compatible. If a 'swap' version is going to be introduced then
do it this year! don't wait to long with it because it will take at
least one more year before it's on the majority of web servers. A sad
side effect is that php 5.3 won't have a long life since (for the sake
of version numbers) php 5.4 could be here this year!
The way it currently stands is that this feature (just by looking at
the vast +1's) is going to be in php 6.0 but who knows when that's
going to be released! I bet it's not this year and i doubt it will be
anywhere in 2010 so that delays the adaption of this feature by that
time + the time it takes hosts to get php 6.0 (which is between 1 and
2 years) ending up in a total of 3 - 4 years if not included now or in
a 'swap' version.
Just my opinion.
Thanx,
Mark.
I personally would be highly in favor of adding type hinting/casting
BUT with the benifit that php actually becomes faster if you do things
like that. Afterall you can use way more effective c code if you know
what you expect right? As for the version to include type
I sure hope that all the people in favour of this change aren't basing
their opinion on some delusion that it would improve performance in
any way.
--
troels
I personally would be highly in favor of adding type hinting/casting
BUT with the benifit that php actually becomes faster if you do
things
like that. Afterall you can use way more effective c code if you know
what you expect right? As for the version to include typeI sure hope that all the people in favour of this change aren't basing
their opinion on some delusion that it would improve performance in
any way.
well .. this will have an effect on performance.
for one the additional checks will probably add a small overhead for
all users.
the reduction in user land type check code should of course improve
performance.
that being said, none of the above will have a significant relevant
affect on performance in real world applications (which usually spend
most of their time talking to data stores and not type checking).
regards,
Lukas Kahwe Smith
mls@pooteeweet.org