Hi,
I create a new thread to discuss about Scalar type hinting.
Following the John Crenshaw proposed terminology:
- "Strict Typing" means the super strict old C style typing that has been
proven to be ridiculous in this environment because of the obvious problems
inherent in the fact that almost every input is a string.- "Weak Typing" means types in the same sense that the PHP documentation
uses types (for example, the docs indicate substr(string, integer), and
substr(12345, "2") == "345".)- "No Scalar Typing" should be used to indicate the current system (where
there is no provision for hinting at scalar types.)
Previous weak typing proposal could be found here :
https://wiki.php.net/rfc/typechecking
I have no rights to edit the wiki and make a summary of previous arguments,
so if someone could create it...
--
Samuel DEAL
samuel.deal@gmail.com
I'll try to find some time tonight to create that for ya.
Once this discussion comes together a little bit more and we have at least
a vague-ish idea what direction we're moving in, I'll also go ahead and
create an RFC as well so we have a conceptual product to build on.
--Kris
Hi,
I create a new thread to discuss about Scalar type hinting.
Following the John Crenshaw proposed terminology:
- "Strict Typing" means the super strict old C style typing that has
been proven to be ridiculous in this environment because of the obvious
problems inherent in the fact that almost every input is a string.- "Weak Typing" means types in the same sense that the PHP documentation
uses types (for example, the docs indicate substr(string, integer), and
substr(12345, "2") == "345".)- "No Scalar Typing" should be used to indicate the current system
(where there is no provision for hinting at scalar types.)Previous weak typing proposal could be found here :
https://wiki.php.net/rfc/typecheckingI have no rights to edit the wiki and make a summary of previous
arguments, so if someone could create it...--
Samuel DEAL
samuel.deal@gmail.com
What I've wanted for awhile, but don't know what the implementation
problems would be, is to allow for two new variable types to solve
this problem - Strict and tolerant variables. Both of these must be
declared formally (otherwise PHP assumes scalar) and the datatype must
be included. The syntax
// A tolerant variable.
integer $a = 3;
// A strict variable
strict integer $b = 2;
Tolerant variables silently cast values to their declared datatype.
Maybe they should raise E_NOTICE?
Strict variables refuse to be assigned a value with an incorrect
datatype. Raise E_WARNING?
A strict function would have the current behavior of kicking a warning
when the type hinting fails. Otherwise, functions should be tolerant
function foo ( integer $a, string $b, $c ) {}
strict function foo ( integer $a, $string $b, $c ) {}
A function parameter without a datatype would be ignored.
This does open the door to function overloading, but the engine
problems of this are well documented and have been discussed. Still,
I don't think it's a bad thing to have a syntax that allows for method
overloading in the future.
I'll try to find some time tonight to create that for ya.
Once this discussion comes together a little bit more and we have at least
a vague-ish idea what direction we're moving in, I'll also go ahead and
create an RFC as well so we have a conceptual product to build on.--Kris
Hi,
I create a new thread to discuss about Scalar type hinting.
Following the John Crenshaw proposed terminology:
- "Strict Typing" means the super strict old C style typing that has
been proven to be ridiculous in this environment because of the obvious
problems inherent in the fact that almost every input is a string.- "Weak Typing" means types in the same sense that the PHP documentation
uses types (for example, the docs indicate substr(string, integer), and
substr(12345, "2") == "345".)- "No Scalar Typing" should be used to indicate the current system
(where there is no provision for hinting at scalar types.)Previous weak typing proposal could be found here :
https://wiki.php.net/rfc/typecheckingI have no rights to edit the wiki and make a summary of previous
arguments, so if someone could create it...--
Samuel DEAL
samuel.deal@gmail.com
Michael Morris,
Type hinting means that we have hints when declaring function/method
signatures, example:
functiion do(int $someVal) {}
function doOther(string $str, mixed $pos = null) {}
As I remember, there was never a discussion about adding type hints
when declaring vars. The original discussion was and is about
finishing the support for type hints because PHP allready has
typehinting for arrays and objects. Additionaly there was launched a
discussion about function/method return typehints.
I do think the variable declaration type hints are pointless because
variables are chaning their types on the fly. But mostly it will
polute current discussion even more and adds a whole new super-global
level of thinking through and implementation details. It's just too
much.
We had type hinting discussions for a few years now and never reached
any conclusion and patches that have been made still had lots of
problems. We should really focus on param type hints and maybe on
return type hints for now and see where it takes us.
Because the new thread has been created, I will leave my arguments
here for the record.
I, as a user land developer, would like the weak type hinting, which
takes care of transparent conversions where no data loss is happening.
I would like to get a E_NOTICE or E_WARNING when some loss is
happening (for example I pass a string "aaa", but function expects an
integer or double. It would convert it to 1, but also will emit the
warning/notice for me to inspect what went wrong). And fatal errors on
serious type miss match like it is now done with objects and arrays.
This way is 100% backwards compatible, it does not add a ton of new
rules to remember when write code and is based on the mechanics PHP
already has, just extended a little. Same goes for the return type
hints.
The only case I do not remember being discussed in detail (maybe it
was and I somehow missed that part) is when we accept (and return for
return type hints) a mixed type param. Is it somehow described or we
just leave out the type hints at all. It's not so rare to see
something like this: function do(string $str = null). By logic it
accepts 2 types - null and string, but type hint says it accepts only
string and doing a call do(null) should work despite the type hint.
My 2 cents.
Hi,
PHP is no strickt-typed language. Changing this is a massive change, if
you want to go there: There are plenty of other languages.
If you want this to be an optional feature:
a) It's not optional (one has to maintain code written by others, uses
libraries, frameworks, ...)
b) It causes a hell lot of trouble with copy-on-write. going from
fixed-typed to non-fixed-typed variables (in a funciton call or
assignment or such) will always have to cause a copy. This will hurt the
performance in hardly predictable ways.
johannes
What I've wanted for awhile, but don't know what the implementation
problems would be, is to allow for two new variable types to solve
this problem - Strict and tolerant variables. Both of these must be
declared formally (otherwise PHP assumes scalar) and the datatype must
be included. The syntax// A tolerant variable.
integer $a = 3;// A strict variable
strict integer $b = 2;Tolerant variables silently cast values to their declared datatype.
Maybe they should raise E_NOTICE?
Strict variables refuse to be assigned a value with an incorrect
datatype. Raise E_WARNING?A strict function would have the current behavior of kicking a warning
when the type hinting fails. Otherwise, functions should be tolerantfunction foo ( integer $a, string $b, $c ) {}
strict function foo ( integer $a, $string $b, $c ) {}
A function parameter without a datatype would be ignored.
This does open the door to function overloading, but the engine
problems of this are well documented and have been discussed. Still,
I don't think it's a bad thing to have a syntax that allows for method
overloading in the future.I'll try to find some time tonight to create that for ya.
Once this discussion comes together a little bit more and we have at least
a vague-ish idea what direction we're moving in, I'll also go ahead and
create an RFC as well so we have a conceptual product to build on.--Kris
Hi,
I create a new thread to discuss about Scalar type hinting.
Following the John Crenshaw proposed terminology:
- "Strict Typing" means the super strict old C style typing that has
been proven to be ridiculous in this environment because of the obvious
problems inherent in the fact that almost every input is a string.- "Weak Typing" means types in the same sense that the PHP documentation
uses types (for example, the docs indicate substr(string, integer), and
substr(12345, "2") == "345".)- "No Scalar Typing" should be used to indicate the current system
(where there is no provision for hinting at scalar types.)Previous weak typing proposal could be found here :
https://wiki.php.net/rfc/typecheckingI have no rights to edit the wiki and make a summary of previous
arguments, so if someone could create it...--
Samuel DEAL
samuel.deal@gmail.com
2012/2/27 Johannes Schlüter johannes@schlueters.de
Hi,
PHP is no strickt-typed language. Changing this is a massive change, if
you want to go there: There are plenty of other languages.If you want this to be an optional feature:
a) It's not optional (one has to maintain code written by others, uses
libraries, frameworks, ...)
b) It causes a hell lot of trouble with copy-on-write. going from
fixed-typed to non-fixed-typed variables (in a funciton call or
assignment or such) will always have to cause a copy. This will hurt the
performance in hardly predictable ways.johannes
Big +1 from me. Thanks for the post Johannes!
It makes sense to have a type hint for the different type of data
structures.
- array
- object ( class name for OOP ).
The scalar values (int, string, double) are type-less, flexible and should
remain that way. If you want strict typehinting then move to another
language.
What I've wanted for awhile, but don't know what the implementation
problems would be, is to allow for two new variable types to solve
this problem - Strict and tolerant variables. Both of these must be
declared formally (otherwise PHP assumes scalar) and the datatype must
be included. The syntax// A tolerant variable.
integer $a = 3;// A strict variable
strict integer $b = 2;Tolerant variables silently cast values to their declared datatype.
Maybe they should raise E_NOTICE?
Strict variables refuse to be assigned a value with an incorrect
datatype. Raise E_WARNING?A strict function would have the current behavior of kicking a warning
when the type hinting fails. Otherwise, functions should be tolerantfunction foo ( integer $a, string $b, $c ) {}
strict function foo ( integer $a, $string $b, $c ) {}
A function parameter without a datatype would be ignored.
This does open the door to function overloading, but the engine
problems of this are well documented and have been discussed. Still,
I don't think it's a bad thing to have a syntax that allows for method
overloading in the future.On Sun, Feb 26, 2012 at 10:52 PM, Kris Craig kris.craig@gmail.com
wrote:I'll try to find some time tonight to create that for ya.
Once this discussion comes together a little bit more and we have at
least
a vague-ish idea what direction we're moving in, I'll also go ahead and
create an RFC as well so we have a conceptual product to build on.--Kris
On Sun, Feb 26, 2012 at 6:27 PM, Samuel Deal samuel.deal@gmail.com
wrote:Hi,
I create a new thread to discuss about Scalar type hinting.
Following the John Crenshaw proposed terminology:
- "Strict Typing" means the super strict old C style typing that has
been proven to be ridiculous in this environment because of the
obvious
problems inherent in the fact that almost every input is a string.- "Weak Typing" means types in the same sense that the PHP
documentation
uses types (for example, the docs indicate substr(string, integer),
and
substr(12345, "2") == "345".)- "No Scalar Typing" should be used to indicate the current system
(where there is no provision for hinting at scalar types.)Previous weak typing proposal could be found here :
https://wiki.php.net/rfc/typecheckingI have no rights to edit the wiki and make a summary of previous
arguments, so if someone could create it...--
Samuel DEAL
samuel.deal@gmail.com
But what about optional weak (auto-convert) type hints? They should
make life if not easier, definitively a little richer when writing
API's and internal stuff, where some additional strictness and
warnings generated make sense.
And it definitively makes IDE's more happy and easier to generate
PHPDoc blocks, not to mention Reflection stuff can be added and find
it's uses pretty fast.
I see it as anonymous functions - you can definitively live without
them, but they are wonderful and made some functionality better (for
example Yii Framework used eval for many things and with PHP 5.3 we
just started to use anonymous functions instead - the support was
build in before the 5.3 even started) - same I see happening here in
the future.
But yes, any major work that changes things a lot will just make a
mess and many BC issues.
2012/2/27 Paul Dragoonis dragoonis@gmail.com:
2012/2/27 Johannes Schlüter johannes@schlueters.de
Hi,
PHP is no strickt-typed language. Changing this is a massive change, if
you want to go there: There are plenty of other languages.If you want this to be an optional feature:
a) It's not optional (one has to maintain code written by others, uses
libraries, frameworks, ...)
b) It causes a hell lot of trouble with copy-on-write. going from
fixed-typed to non-fixed-typed variables (in a funciton call or
assignment or such) will always have to cause a copy. This will hurt the
performance in hardly predictable ways.johannes
Big +1 from me. Thanks for the post Johannes!
It makes sense to have a type hint for the different type of data
structures.
- array
- object ( class name for OOP ).
The scalar values (int, string, double) are type-less, flexible and should
remain that way. If you want strict typehinting then move to another
language.What I've wanted for awhile, but don't know what the implementation
problems would be, is to allow for two new variable types to solve
this problem - Strict and tolerant variables. Both of these must be
declared formally (otherwise PHP assumes scalar) and the datatype must
be included. The syntax// A tolerant variable.
integer $a = 3;// A strict variable
strict integer $b = 2;Tolerant variables silently cast values to their declared datatype.
Maybe they should raise E_NOTICE?
Strict variables refuse to be assigned a value with an incorrect
datatype. Raise E_WARNING?A strict function would have the current behavior of kicking a warning
when the type hinting fails. Otherwise, functions should be tolerantfunction foo ( integer $a, string $b, $c ) {}
strict function foo ( integer $a, $string $b, $c ) {}
A function parameter without a datatype would be ignored.
This does open the door to function overloading, but the engine
problems of this are well documented and have been discussed. Still,
I don't think it's a bad thing to have a syntax that allows for method
overloading in the future.On Sun, Feb 26, 2012 at 10:52 PM, Kris Craig kris.craig@gmail.com
wrote:I'll try to find some time tonight to create that for ya.
Once this discussion comes together a little bit more and we have at
least
a vague-ish idea what direction we're moving in, I'll also go ahead and
create an RFC as well so we have a conceptual product to build on.--Kris
On Sun, Feb 26, 2012 at 6:27 PM, Samuel Deal samuel.deal@gmail.com
wrote:Hi,
I create a new thread to discuss about Scalar type hinting.
Following the John Crenshaw proposed terminology:
- "Strict Typing" means the super strict old C style typing that has
been proven to be ridiculous in this environment because of the
obvious
problems inherent in the fact that almost every input is a string.- "Weak Typing" means types in the same sense that the PHP
documentation
uses types (for example, the docs indicate substr(string, integer),
and
substr(12345, "2") == "345".)- "No Scalar Typing" should be used to indicate the current system
(where there is no provision for hinting at scalar types.)Previous weak typing proposal could be found here :
https://wiki.php.net/rfc/typecheckingI have no rights to edit the wiki and make a summary of previous
arguments, so if someone could create it...--
Samuel DEAL
samuel.deal@gmail.com
So the official response is "get lost"?
I don't know about the internals implications. But from an external
API standpoint I see no problem in allowing programmers who want to
strictly enforce a variable's datatype to do so. Legacy code would
not be affected unless it was trying to use the new reserved word
"strict"
2012/2/27 Johannes Schlüter johannes@schlueters.de:
Hi,
PHP is no strickt-typed language. Changing this is a massive change, if
you want to go there: There are plenty of other languages.If you want this to be an optional feature:
a) It's not optional (one has to maintain code written by others, uses
libraries, frameworks, ...)
b) It causes a hell lot of trouble with copy-on-write. going from
fixed-typed to non-fixed-typed variables (in a funciton call or
assignment or such) will always have to cause a copy. This will hurt the
performance in hardly predictable ways.johannes
What I've wanted for awhile, but don't know what the implementation
problems would be, is to allow for two new variable types to solve
this problem - Strict and tolerant variables. Both of these must be
declared formally (otherwise PHP assumes scalar) and the datatype must
be included. The syntax// A tolerant variable.
integer $a = 3;// A strict variable
strict integer $b = 2;Tolerant variables silently cast values to their declared datatype.
Maybe they should raise E_NOTICE?
Strict variables refuse to be assigned a value with an incorrect
datatype. Raise E_WARNING?A strict function would have the current behavior of kicking a warning
when the type hinting fails. Otherwise, functions should be tolerantfunction foo ( integer $a, string $b, $c ) {}
strict function foo ( integer $a, $string $b, $c ) {}
A function parameter without a datatype would be ignored.
This does open the door to function overloading, but the engine
problems of this are well documented and have been discussed. Still,
I don't think it's a bad thing to have a syntax that allows for method
overloading in the future.I'll try to find some time tonight to create that for ya.
Once this discussion comes together a little bit more and we have at least
a vague-ish idea what direction we're moving in, I'll also go ahead and
create an RFC as well so we have a conceptual product to build on.--Kris
Hi,
I create a new thread to discuss about Scalar type hinting.
Following the John Crenshaw proposed terminology:
- "Strict Typing" means the super strict old C style typing that has
been proven to be ridiculous in this environment because of the obvious
problems inherent in the fact that almost every input is a string.- "Weak Typing" means types in the same sense that the PHP documentation
uses types (for example, the docs indicate substr(string, integer), and
substr(12345, "2") == "345".)- "No Scalar Typing" should be used to indicate the current system
(where there is no provision for hinting at scalar types.)Previous weak typing proposal could be found here :
https://wiki.php.net/rfc/typecheckingI have no rights to edit the wiki and make a summary of previous
arguments, so if someone could create it...--
Samuel DEAL
samuel.deal@gmail.com
On Mon, Feb 27, 2012 at 5:16 PM, Michael Morris dmgx.michael@gmail.comwrote:
So the official response is "get lost"?
no, it is: "come back after you did your homework, and you can provide new
arguments to the discussion"
I don't know about the internals implications. But from an external
API standpoint I see no problem in allowing programmers who want to
strictly enforce a variable's datatype to do so. Legacy code would
not be affected unless it was trying to use the new reserved word
"strict"
it was discussed before, strict typing tends to be "viral", in the sense
that the developer using a lib which enforces method signatures using type
hinting can either:
- write a lot of boiler plate code to make sure that he/she is passing the
expected types (notice that strict typing would pass that burden to the api
consumer, which is against the Generous on input, strict on output
paradigm, plus it would generate much more work, as there are always more
consumers than producers) - or simply passing those requirements up in the call chain, which is less
work, but affects even more code, and in the end, turns the whole app into
strict typing.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
no, it is: "come back after you did your homework, and you can provide new
arguments to the discussion"
To be completely fair, I did homework on this. I went back to 2000 on
marc.info's archives and read almost all of the 400 posts matching the
search http://marc.info/?l=php-internals&w=2&r=13&s=strict+typing&q=b
and a bunch of the posts on
http://marc.info/?l=php-internals&w=2&r=54&s=type+hinting&q=b
The vast majority of what I found were quite good arguments for
including the feature. I found quite a bit of "this was discussed to
death, do your homework and provide new arguments". What's odd, is
that one of the earliest on-topic threads that I found (2007:
http://marc.info/?l=php-internals&m=119514660125258&w=2 ) had this as
the third reply. The only on-topic discussion that I found prior to
that was in 2006 (almost exactly 1 year prior:
http://marc.info/?l=php-internals&m=116257685415135&w=2 ).
Discussed to death. Yet only one time before (discussing a specific patch)...
And the opponents still said no...
There were also quite a few problems identified with scalar hinting
and auto-casting vs strict erroring. However, there were also
solutions proposed to nearly each and every one of them.
And the opponents still said no...
It has been brought up time and time again. Solutions have been
proposed which have no fundimental issues (inconsistencies,
problematic operations - such as references, etc)...
And the opponents instead said "this has been discussed to death, no"...
Please can you stop saying "this has been discussed to death". To be
frank, don't stop the discussion because you don't like the idea. It
has been discussed to death. But the discussion has only really ever
involved people who are for it. The opponents by and large have used
two arguments: "It has been discussed already, so no" and "don't make
PHP into Java".
There has been some discussion of technical merit and problem
resolution by opponents, but finding it is VERY difficult among all
the down trodding commentary.
So let me make a plea:
If you don't like this feature, and you can explain from a TECHNICAL
perspective why, please do so! If you don't like the feature, and are
going to lean on "It's not Java", or "We've discussed this to death
already", please don't...
And to be fair: "and you can provide new arguments to the discussion"
has already happened quite a bit (dating back the past 5 years), but
those arguments were ignored or overruled for political reasons.
Anthony
On Mon, Feb 27, 2012 at 5:16 PM, Michael Morris dmgx.michael@gmail.comwrote:
So the official response is "get lost"?
no, it is: "come back after you did your homework, and you can provide new
arguments to the discussion"I don't know about the internals implications. But from an external
API standpoint I see no problem in allowing programmers who want to
strictly enforce a variable's datatype to do so. Legacy code would
not be affected unless it was trying to use the new reserved word
"strict"it was discussed before, strict typing tends to be "viral", in the sense
that the developer using a lib which enforces method signatures using type
hinting can either:
- write a lot of boiler plate code to make sure that he/she is passing the
expected types (notice that strict typing would pass that burden to the api
consumer, which is against the Generous on input, strict on output
paradigm, plus it would generate much more work, as there are always more
consumers than producers)- or simply passing those requirements up in the call chain, which is less
work, but affects even more code, and in the end, turns the whole app into
strict typing.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Anthony,
Remember you're dealing with the internals list. :)
I kind of like the idea of having long proper discussions on a
particular topic. But let's face it, that's an utopic view (at best)!
Even if optional, and even if backwards compatible, there are a number
of things that will be quite hard to change, ranging from "it's very
difficult/impossible to implement properly", to "this isn't the PHP
way"...
Just check out the discussions regarding function naming and/or
parameter order and you'll understand, some things will remain; but
remember the golden rule:
<?php echo 'PHP ' . (PHP_MAJOR_VERSION + 1) . ' will fix it!'; ?>
Cheers,
~ Daniel
+1 what Anthony said.
Guys, seriously. Some of these responses have been downright rude and
inappropriate for a constructive dialogue. Please do not pollute this
thread with cliche, "Just find another language and get out!" posts. It
doesn't add anything to the conversation and instead just creates needless
anger and animosity. It's immature and just makes it look like we're
incapable of having a rational discussion.
So, let me outline a list of "arguments" that will carry ZERO weight on
this thread:
- "If you don't like PHP as it is, goto Java (or some other language)!"
- "We've already talked about this before. Therefore, we must never
speak of it again." - "This is impossible. Why? Because I said so. You want evidence?
Fuck you." - "But this would require significant changes to the core source code!
We'd never be able to find enough sacrificial penguins to appease the gods!" - "Anyone who likes this idea is either stupid or not a 'true' PHP
developer." - "If you disagree with me, it means you haven't done your homework
because I'm always right." - "Strict typing would break everything! What? You're not talking
about C-like strict typing? Sorry, I didn't catch that. Strict typing
would break everything!...." - "I don't care if you've already countered my argument. I'll just keep
repeating myself as if you didn't."
Variations of the above statements have been posted ad nauseum. They're
all based on logical fallacies and are not constructive.
I'm putting this out there: If anyone posts one or more of the above
arguments yet again on this topic, I will personally extract one of your
kidneys and sell it to a questionable "dog food" company in Shanghai. I
will then openly mock your intellectual laziness and encourage people to
ignore you. ;P
I'd love to prove Daniel wrong, but I think he may be on to something....
:\
--Kris
On Mon, Feb 27, 2012 at 9:38 AM, Anthony Ferrara ircmaxell@gmail.comwrote:
no, it is: "come back after you did your homework, and you can provide
new
arguments to the discussion"To be completely fair, I did homework on this. I went back to 2000 on
marc.info's archives and read almost all of the 400 posts matching the
search http://marc.info/?l=php-internals&w=2&r=13&s=strict+typing&q=b
and a bunch of the posts on
http://marc.info/?l=php-internals&w=2&r=54&s=type+hinting&q=bThe vast majority of what I found were quite good arguments for
including the feature. I found quite a bit of "this was discussed to
death, do your homework and provide new arguments". What's odd, is
that one of the earliest on-topic threads that I found (2007:
http://marc.info/?l=php-internals&m=119514660125258&w=2 ) had this as
the third reply. The only on-topic discussion that I found prior to
that was in 2006 (almost exactly 1 year prior:
http://marc.info/?l=php-internals&m=116257685415135&w=2 ).Discussed to death. Yet only one time before (discussing a specific
patch)...And the opponents still said no...
There were also quite a few problems identified with scalar hinting
and auto-casting vs strict erroring. However, there were also
solutions proposed to nearly each and every one of them.And the opponents still said no...
It has been brought up time and time again. Solutions have been
proposed which have no fundimental issues (inconsistencies,
problematic operations - such as references, etc)...And the opponents instead said "this has been discussed to death, no"...
Please can you stop saying "this has been discussed to death". To be
frank, don't stop the discussion because you don't like the idea. It
has been discussed to death. But the discussion has only really ever
involved people who are for it. The opponents by and large have used
two arguments: "It has been discussed already, so no" and "don't make
PHP into Java".There has been some discussion of technical merit and problem
resolution by opponents, but finding it is VERY difficult among all
the down trodding commentary.So let me make a plea:
If you don't like this feature, and you can explain from a TECHNICAL
perspective why, please do so! If you don't like the feature, and are
going to lean on "It's not Java", or "We've discussed this to death
already", please don't...And to be fair: "and you can provide new arguments to the discussion"
has already happened quite a bit (dating back the past 5 years), but
those arguments were ignored or overruled for political reasons.Anthony
On Mon, Feb 27, 2012 at 5:16 PM, Michael Morris <dmgx.michael@gmail.com
wrote:So the official response is "get lost"?
no, it is: "come back after you did your homework, and you can provide
new
arguments to the discussion"I don't know about the internals implications. But from an external
API standpoint I see no problem in allowing programmers who want to
strictly enforce a variable's datatype to do so. Legacy code would
not be affected unless it was trying to use the new reserved word
"strict"it was discussed before, strict typing tends to be "viral", in the sense
that the developer using a lib which enforces method signatures using
type
hinting can either:
- write a lot of boiler plate code to make sure that he/she is passing
the
expected types (notice that strict typing would pass that burden to the
api
consumer, which is against the Generous on input, strict on output
paradigm, plus it would generate much more work, as there are always more
consumers than producers)- or simply passing those requirements up in the call chain, which is
less
work, but affects even more code, and in the end, turns the whole app
into
strict typing.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Now, to rewind a bit past the latest chunk of "I hate this idea" posts....
I'd like to suggest a new term: "strong".
This term would be similar to "weak", except with a few key differences:
- Weak would behave very much like Arvids suggested in his earlier post;
i.e. if the variable is an integer but you pass a string (like "aaa") to
it, a warning would be thrown and PHP would attempt to convert it (i.e. it
would become 1). - Strong, on the other hand, would throw a fatal error if you attempted
to pass an incompatible value to an array. Or, to put it another way, if
the "converted" value does not match the original value. For example, if
we're assigning "aaa" to an integer, that would convert to 1; and, since
"1" != "aaa", a fatal error would be thrown. On the other hand, if you
were to pass the string "1" to that integer variable, it would convert to
1; and, since "1" == 1, there wouldn't be a problem. - In both instances, if the converted value matches the original (i.e.
"1" == 1), no warning error would be displayed. Should it perhaps display
a notice though? Or no error at all? I can think of reasonable arguments
on both sides of that question.
This new term would also make it easier for us to avoid using the term
"strict," which would explode even in the case of "1" == 1.
Whether this should be done at the function level, the variable level, or
both is an open-ended question.
Some possible examples of how this would look:
weak int $i = "aaa"; // Converts to 1 and throws a warning.
strong int $ii = "aaa"; // Throws a fatal error.
weak int $i = "1"; // Converts to 1.
strong int $ii = "1"; // Converts to 1.
--Kris
+1 what Anthony said.
Guys, seriously. Some of these responses have been downright rude and
inappropriate for a constructive dialogue. Please do not pollute this
thread with cliche, "Just find another language and get out!" posts. It
doesn't add anything to the conversation and instead just creates needless
anger and animosity. It's immature and just makes it look like we're
incapable of having a rational discussion.So, let me outline a list of "arguments" that will carry ZERO weight on
this thread:
- "If you don't like PHP as it is, goto Java (or some other language)!"
- "We've already talked about this before. Therefore, we must never
speak of it again."- "This is impossible. Why? Because I said so. You want evidence?
Fuck you."- "But this would require significant changes to the core source
code! We'd never be able to find enough sacrificial penguins to appease
the gods!"- "Anyone who likes this idea is either stupid or not a 'true' PHP
developer."- "If you disagree with me, it means you haven't done your homework
because I'm always right."- "Strict typing would break everything! What? You're not talking
about C-like strict typing? Sorry, I didn't catch that. Strict typing
would break everything!...."- "I don't care if you've already countered my argument. I'll just
keep repeating myself as if you didn't."Variations of the above statements have been posted ad nauseum. They're
all based on logical fallacies and are not constructive.I'm putting this out there: If anyone posts one or more of the above
arguments yet again on this topic, I will personally extract one of your
kidneys and sell it to a questionable "dog food" company in Shanghai. I
will then openly mock your intellectual laziness and encourage people to
ignore you. ;PI'd love to prove Daniel wrong, but I think he may be on to something....
:\--Kris
On Mon, Feb 27, 2012 at 9:38 AM, Anthony Ferrara ircmaxell@gmail.comwrote:
no, it is: "come back after you did your homework, and you can provide
new
arguments to the discussion"To be completely fair, I did homework on this. I went back to 2000 on
marc.info's archives and read almost all of the 400 posts matching the
search http://marc.info/?l=php-internals&w=2&r=13&s=strict+typing&q=b
and a bunch of the posts on
http://marc.info/?l=php-internals&w=2&r=54&s=type+hinting&q=bThe vast majority of what I found were quite good arguments for
including the feature. I found quite a bit of "this was discussed to
death, do your homework and provide new arguments". What's odd, is
that one of the earliest on-topic threads that I found (2007:
http://marc.info/?l=php-internals&m=119514660125258&w=2 ) had this as
the third reply. The only on-topic discussion that I found prior to
that was in 2006 (almost exactly 1 year prior:
http://marc.info/?l=php-internals&m=116257685415135&w=2 ).Discussed to death. Yet only one time before (discussing a specific
patch)...And the opponents still said no...
There were also quite a few problems identified with scalar hinting
and auto-casting vs strict erroring. However, there were also
solutions proposed to nearly each and every one of them.And the opponents still said no...
It has been brought up time and time again. Solutions have been
proposed which have no fundimental issues (inconsistencies,
problematic operations - such as references, etc)...And the opponents instead said "this has been discussed to death, no"...
Please can you stop saying "this has been discussed to death". To be
frank, don't stop the discussion because you don't like the idea. It
has been discussed to death. But the discussion has only really ever
involved people who are for it. The opponents by and large have used
two arguments: "It has been discussed already, so no" and "don't make
PHP into Java".There has been some discussion of technical merit and problem
resolution by opponents, but finding it is VERY difficult among all
the down trodding commentary.So let me make a plea:
If you don't like this feature, and you can explain from a TECHNICAL
perspective why, please do so! If you don't like the feature, and are
going to lean on "It's not Java", or "We've discussed this to death
already", please don't...And to be fair: "and you can provide new arguments to the discussion"
has already happened quite a bit (dating back the past 5 years), but
those arguments were ignored or overruled for political reasons.Anthony
On Mon, Feb 27, 2012 at 5:16 PM, Michael Morris <dmgx.michael@gmail.com
wrote:So the official response is "get lost"?
no, it is: "come back after you did your homework, and you can provide
new
arguments to the discussion"I don't know about the internals implications. But from an external
API standpoint I see no problem in allowing programmers who want to
strictly enforce a variable's datatype to do so. Legacy code would
not be affected unless it was trying to use the new reserved word
"strict"it was discussed before, strict typing tends to be "viral", in the sense
that the developer using a lib which enforces method signatures using
type
hinting can either:
- write a lot of boiler plate code to make sure that he/she is passing
the
expected types (notice that strict typing would pass that burden to the
api
consumer, which is against the Generous on input, strict on output
paradigm, plus it would generate much more work, as there are always
more
consumers than producers)- or simply passing those requirements up in the call chain, which is
less
work, but affects even more code, and in the end, turns the whole app
into
strict typing.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Err typo correction: "Strong, on the other hand, would throw a fatal error
if you attempted to pass an incompatible value to *a variable." (not "an
array")
--Kris
Now, to rewind a bit past the latest chunk of "I hate this idea" posts....
I'd like to suggest a new term: "strong".
This term would be similar to "weak", except with a few key differences:
- Weak would behave very much like Arvids suggested in his earlier
post; i.e. if the variable is an integer but you pass a string (like "aaa")
to it, a warning would be thrown and PHP would attempt to convert it (i.e.
it would become 1).- Strong, on the other hand, would throw a fatal error if you
attempted to pass an incompatible value to an array. Or, to put it another
way, if the "converted" value does not match the original value. For
example, if we're assigning "aaa" to an integer, that would convert to 1;
and, since "1" != "aaa", a fatal error would be thrown. On the other hand,
if you were to pass the string "1" to that integer variable, it would
convert to 1; and, since "1" == 1, there wouldn't be a problem.- In both instances, if the converted value matches the original (i.e.
"1" == 1), no warning error would be displayed. Should it perhaps display
a notice though? Or no error at all? I can think of reasonable arguments
on both sides of that question.This new term would also make it easier for us to avoid using the term
"strict," which would explode even in the case of "1" == 1.Whether this should be done at the function level, the variable level, or
both is an open-ended question.Some possible examples of how this would look:
weak int $i = "aaa"; // Converts to 1 and throws a warning.
strong int $ii = "aaa"; // Throws a fatal error.
weak int $i = "1"; // Converts to 1.
strong int $ii = "1"; // Converts to 1.--Kris
+1 what Anthony said.
Guys, seriously. Some of these responses have been downright rude and
inappropriate for a constructive dialogue. Please do not pollute this
thread with cliche, "Just find another language and get out!" posts. It
doesn't add anything to the conversation and instead just creates needless
anger and animosity. It's immature and just makes it look like we're
incapable of having a rational discussion.So, let me outline a list of "arguments" that will carry ZERO weight on
this thread:
- "If you don't like PHP as it is, goto Java (or some other
language)!"- "We've already talked about this before. Therefore, we must never
speak of it again."- "This is impossible. Why? Because I said so. You want evidence?
Fuck you."- "But this would require significant changes to the core source
code! We'd never be able to find enough sacrificial penguins to appease
the gods!"- "Anyone who likes this idea is either stupid or not a 'true' PHP
developer."- "If you disagree with me, it means you haven't done your homework
because I'm always right."- "Strict typing would break everything! What? You're not talking
about C-like strict typing? Sorry, I didn't catch that. Strict typing
would break everything!...."- "I don't care if you've already countered my argument. I'll just
keep repeating myself as if you didn't."Variations of the above statements have been posted ad nauseum. They're
all based on logical fallacies and are not constructive.I'm putting this out there: If anyone posts one or more of the above
arguments yet again on this topic, I will personally extract one of your
kidneys and sell it to a questionable "dog food" company in Shanghai. I
will then openly mock your intellectual laziness and encourage people to
ignore you. ;PI'd love to prove Daniel wrong, but I think he may be on to
something.... :\--Kris
On Mon, Feb 27, 2012 at 9:38 AM, Anthony Ferrara ircmaxell@gmail.comwrote:
no, it is: "come back after you did your homework, and you can provide
new
arguments to the discussion"To be completely fair, I did homework on this. I went back to 2000 on
marc.info's archives and read almost all of the 400 posts matching the
search http://marc.info/?l=php-internals&w=2&r=13&s=strict+typing&q=b
and a bunch of the posts on
http://marc.info/?l=php-internals&w=2&r=54&s=type+hinting&q=bThe vast majority of what I found were quite good arguments for
including the feature. I found quite a bit of "this was discussed to
death, do your homework and provide new arguments". What's odd, is
that one of the earliest on-topic threads that I found (2007:
http://marc.info/?l=php-internals&m=119514660125258&w=2 ) had this as
the third reply. The only on-topic discussion that I found prior to
that was in 2006 (almost exactly 1 year prior:
http://marc.info/?l=php-internals&m=116257685415135&w=2 ).Discussed to death. Yet only one time before (discussing a specific
patch)...And the opponents still said no...
There were also quite a few problems identified with scalar hinting
and auto-casting vs strict erroring. However, there were also
solutions proposed to nearly each and every one of them.And the opponents still said no...
It has been brought up time and time again. Solutions have been
proposed which have no fundimental issues (inconsistencies,
problematic operations - such as references, etc)...And the opponents instead said "this has been discussed to death, no"...
Please can you stop saying "this has been discussed to death". To be
frank, don't stop the discussion because you don't like the idea. It
has been discussed to death. But the discussion has only really ever
involved people who are for it. The opponents by and large have used
two arguments: "It has been discussed already, so no" and "don't make
PHP into Java".There has been some discussion of technical merit and problem
resolution by opponents, but finding it is VERY difficult among all
the down trodding commentary.So let me make a plea:
If you don't like this feature, and you can explain from a TECHNICAL
perspective why, please do so! If you don't like the feature, and are
going to lean on "It's not Java", or "We've discussed this to death
already", please don't...And to be fair: "and you can provide new arguments to the discussion"
has already happened quite a bit (dating back the past 5 years), but
those arguments were ignored or overruled for political reasons.Anthony
On Mon, Feb 27, 2012 at 11:55 AM, Ferenc Kovacs tyra3l@gmail.com
wrote:On Mon, Feb 27, 2012 at 5:16 PM, Michael Morris <
dmgx.michael@gmail.com>wrote:So the official response is "get lost"?
no, it is: "come back after you did your homework, and you can provide
new
arguments to the discussion"I don't know about the internals implications. But from an external
API standpoint I see no problem in allowing programmers who want to
strictly enforce a variable's datatype to do so. Legacy code would
not be affected unless it was trying to use the new reserved word
"strict"it was discussed before, strict typing tends to be "viral", in the
sense
that the developer using a lib which enforces method signatures using
type
hinting can either:
- write a lot of boiler plate code to make sure that he/she is passing
the
expected types (notice that strict typing would pass that burden to
the api
consumer, which is against the Generous on input, strict on output
paradigm, plus it would generate much more work, as there are always
more
consumers than producers)- or simply passing those requirements up in the call chain, which is
less
work, but affects even more code, and in the end, turns the whole app
into
strict typing.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Now, to rewind a bit past the latest chunk of "I hate this idea" posts....
I'd like to suggest a new term: "strong".
This term would be similar to "weak", except with a few key differences:
- Weak would behave very much like Arvids suggested in his earlier post;
i.e. if the variable is an integer but you pass a string (like "aaa") to
it, a warning would be thrown and PHP would attempt to convert it (i.e.
it
would become 1).- Strong, on the other hand, would throw a fatal error if you attempted
to pass an incompatible value to an array. Or, to put it another way, if
the "converted" value does not match the original value. For example, if
we're assigning "aaa" to an integer, that would convert to 1; and, since
"1" != "aaa", a fatal error would be thrown. On the other hand, if you
were to pass the string "1" to that integer variable, it would convert to
1; and, since "1" == 1, there wouldn't be a problem.- In both instances, if the converted value matches the original (i.e.
"1" == 1), no warning error would be displayed. Should it perhaps
display
a notice though? Or no error at all? I can think of reasonable
arguments
on both sides of that question.This new term would also make it easier for us to avoid using the term
"strict," which would explode even in the case of "1" == 1.Whether this should be done at the function level, the variable level, or
both is an open-ended question.Some possible examples of how this would look:
weak int $i = "aaa"; // Converts to 1 and throws a warning.
strong int $ii = "aaa"; // Throws a fatal error.
weak int $i = "1"; // Converts to 1.
strong int $ii = "1"; // Converts to 1.--Kris
Maybe this discussion should start from the end of the last discussion on
non-strict type hints, where really smart people came up with some options
to handle the conversion:
The RFC talks about throwing E_STRICT or E_FATAL, and has a couple of
options for a matrix of conversion rules.
I don't think we need another name for weak type hints, since the name
covers anything less than strict, and anything more than none. There's been
enough confusion about the names of things without adding another name for
a variation of weak type hints.
If I recall, the previous effort died due to the emotional stress of
getting to the point where the differences between strict type hints and
non-strict type hints was well understood, and everyone's position on those
two points was crystallized. There were still a few proponents of strict
type hints, but it seemed they were willing to live with non-strict type
hints. At that point, everyone became more interested in having a 5.4, and
scalar type hints were left for a time.
Hopefully I haven't mischaracterized anyone's position, but I hope it helps
us move beyond previously trod ground.
John
-----Original Message-----
From: John LeSueur [mailto:john.lesueur@gmail.com]Maybe this discussion should start from the end of the last discussion on non-strict type hints, where really smart people came up with some options to handle the conversion:
The RFC talks about throwing
E_STRICTor E_FATAL, and has a couple of options for a matrix of conversion rules.
I've actually read that proposal. To some level it is good, but I felt like there were too many problems. E_ERROR is overkill. For comparison, (function (array $bar) {})('a') generates a catchable fatal error (E_RECOVERABLE_ERROR) so that's the furthest this should go in any case, but when dealing with jugglable types and there's just some unexpected data loss even E_RECOVERABLE_ERROR is too much IMO; E_WARNING or E_NOTICE would be more appropriate. IIRC it also failed conversions too aggressively.
John Crenshaw
Priacta, Inc.
Now, to rewind a bit past the latest chunk of "I hate this idea"
posts....I'd like to suggest a new term: "strong".
This term would be similar to "weak", except with a few key
differences:
- Weak would behave very much like Arvids suggested in his earlier
post;
i.e. if the variable is an integer but you pass a string (like
"aaa") to
it, a warning would be thrown and PHP would attempt to convert it
(i.e. it
would become 1).
Nitpick:
Two backwards compatibility breaks:
- Throwing
E_WARNING - "aaa" converted to (int) is 0.
- Strong, on the other hand, would throw a fatal error if you
attempted
to pass an incompatible value to an array. Or, to put it another
way, if
the "converted" value does not match the original value. For
example, if
we're assigning "aaa" to an integer, that would convert to 1; and,
since
"1" != "aaa", a fatal error would be thrown. On the other hand, if
you
were to pass the string "1" to that integer variable, it would
convert to
1; and, since "1" == 1, there wouldn't be a problem.
Converting "aaa" to 1 causes the error...
Converting "aaa" to the backwards-compatible means "aaa" == 0 will
return TRUE, and your test for reverse engineering will not help.
This is still a nitpick, as I'm sure you could eventually come up with
some way to validate your strict-ness of conversion.
It would be more cumbersome and slower than using PCRE or ctype_* to
validate or === to guarantee the data types match.
But you can do it.
And I'd love to see an extensive patch in an RFC rather than this
endless back-and-forth.
Neither Stas nor I are saying it shouldn't be done.
We're saying it's been tried and failed, but if you want to be the
little engine that could, the proper place is in an RFC with a
community-drive patch that can be evaluated on technical merit.
- In both instances, if the converted value matches the original
(i.e.
"1" == 1), no warning error would be displayed. Should it perhaps
display
a notice though? Or no error at all? I can think of reasonable
arguments
on both sides of that question.
I'm pretty sure backwards-compatibility is going to trump, and "no
error at all" will win out.
This new term would also make it easier for us to avoid using the term
"strict," which would explode even in the case of "1" == 1.
This is a good idea to distinguish between strict typing throughout,
and judiciously applied strict typing.
I fully support calling it "strong" for clarity purposes.
Whether this should be done at the function level, the variable level,
or
both is an open-ended question.
weak int $i = "aaa"; // Converts to 1 and throws a warning.
What purpose would 'weak' serve?
If you want the old default behavior, just leave out the 'weak'.
And we already have (int) $i = "aaa" // converts to 0 as ztype int.
Or perhaps I'm missing something where 'weak' is supposed to invert
the current logic of "aaa" -> 0 and you actually want it to be 1 and
not backwards compatible?
I must be missing something here, then, because that just plain
doesn't make sense to me, personally.
strong int $ii = "aaa"; // Throws a fatal error.
Okay.
E_FATAL seems drastic to me, but I'm not even going to use "strong" so
don't really care either way, I suppose.
I can always set my error handler to over-ride the level of your
error, and even pick out the specifics to change it to whatever I
want...
I respectfully suggest you'll want to discuss the actual level of
error among proponents of the strong typing, and put the consensus in
the RFC.
weak int $i = "1"; // Converts to 1.
Again, old-school (int) or set_type covers this.
Adding new keywords to fulfill the same purpose seems like bloat to me...
strong int $ii = "1"; // Converts to 1.
Okay.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
Inline
-----Original Message-----
From: Richard Lynch [mailto:ceo@l-i-e.com]Now, to rewind a bit past the latest chunk of "I hate this idea"
posts....I'd like to suggest a new term: "strong".
This term would be similar to "weak", except with a few key
differences:
- Weak would behave very much like Arvids suggested in his earlier
post;
i.e. if the variable is an integer but you pass a string (like
"aaa") to
it, a warning would be thrown and PHP would attempt to convert it
(i.e. it
would become 1).Nitpick:
Two backwards compatibility breaks:
- Throwing
E_WARNING- "aaa" converted to (int) is 0.
Sorry, I don't understand the BC break on the warning. Old code doesn't have this anyway, so what exactly would break? Shouldn't all existing scripts continue to work exactly the same as before unless they add a type check?
(I'm sure the example was just wrong, "aaa" should convert to 0)
strong int $ii = "aaa"; // Throws a fatal error.
Okay.
E_FATAL seems drastic to me, but I'm not even going to use "strong" so don't really care either way, I suppose.
I totally agree. E_RECOVERABLE_ERROR is the most severe that this should be (also matches the behavior of current type hints).
weak int $i = "1"; // Converts to 1.
Again, old-school (int) or set_type covers this.
Unfortunately it doesn't completely. Yes, behavior is the same so long as the conversion is good, but a cast will silently accept impossible conversions, which is not what you really want here.
John Crenshaw
Priacta, Inc.
I think this is the main reason for differentiating between "strong" (or
whatever word is appropriate) and "weak." The developer may very well want
their script to blow-up in such a case.
I would liken this to the fact that we have both an "include" statement and
a "require" statement. One is recoverable, the other is not. I think the
same principle applies here.
--Kris
On Mon, Feb 27, 2012 at 2:31 PM, John Crenshaw johncrenshaw@priacta.comwrote:
Inline
-----Original Message-----
From: Richard Lynch [mailto:ceo@l-i-e.com]Now, to rewind a bit past the latest chunk of "I hate this idea"
posts....I'd like to suggest a new term: "strong".
This term would be similar to "weak", except with a few key
differences:
- Weak would behave very much like Arvids suggested in his earlier
post;
i.e. if the variable is an integer but you pass a string (like
"aaa") to
it, a warning would be thrown and PHP would attempt to convert it
(i.e. it
would become 1).Nitpick:
Two backwards compatibility breaks:
- Throwing
E_WARNING- "aaa" converted to (int) is 0.
Sorry, I don't understand the BC break on the warning. Old code doesn't
have this anyway, so what exactly would break? Shouldn't all existing
scripts continue to work exactly the same as before unless they add a type
check?(I'm sure the example was just wrong, "aaa" should convert to 0)
strong int $ii = "aaa"; // Throws a fatal error.
Okay.
E_FATAL seems drastic to me, but I'm not even going to use "strong" so
don't really care either way, I suppose.I totally agree.
E_RECOVERABLE_ERRORis the most severe that this should
be (also matches the behavior of current type hints).weak int $i = "1"; // Converts to 1.
Again, old-school (int) or set_type covers this.
Unfortunately it doesn't completely. Yes, behavior is the same so long as
the conversion is good, but a cast will silently accept impossible
conversions, which is not what you really want here.John Crenshaw
Priacta, Inc.
I think this is the main reason for differentiating between "strong"
(or
whatever word is appropriate) and "weak." The developer may very well
want
their script to blow-up in such a case.
I believe I actually "get it" now...
You want 3 layers:
$a = "1"; //current kosher unchanged
weak int $a = "1"; // some E_x error level
strong int $a = "1"; // some E_y error level where E_y > E_x
Is that a correct summation?
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
@Richard That's fairly close to what I'm thinking, yes. But there seems to
be a diverse range of ideas bouncing around right now, so at present it's
all in flux.
--Kris
I think this is the main reason for differentiating between "strong"
(or
whatever word is appropriate) and "weak." The developer may very well
want
their script to blow-up in such a case.I believe I actually "get it" now...
You want 3 layers:
$a = "1"; //current kosher unchanged
weak int $a = "1"; // some E_x error level
strong int $a = "1"; // some E_y error level where E_y > E_xIs that a correct summation?
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
No, In the example given there's an error on int $a = "1". There should be no error because this juggles fine.
John Crenshaw
Priacta, inc.
-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Tuesday, February 28, 2012 4:47 PM
To: Richard Lynch
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
@Richard That's fairly close to what I'm thinking, yes. But there seems to be a diverse range of ideas bouncing around right now, so at present it's all in flux.
--Kris
I think this is the main reason for differentiating between "strong"
(or
whatever word is appropriate) and "weak." The developer may very
well want their script to blow-up in such a case.I believe I actually "get it" now...
You want 3 layers:
$a = "1"; //current kosher unchanged
weak int $a = "1"; // some E_x error level strong int $a = "1"; //
some E_y error level where E_y > E_xIs that a correct summation?
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=F
S9NLTNEEKWBE--
To unsubscribe,
visit: http://www.php.net/unsub.php
Err sorry yes John is correct. I wasn't paying close enough attention.
Here's my vision of how that progression would look:
$a = "1"; // Current kosher unchanged.
weak int $a = "1"; // Converts to 1. No error thrown.
strong int $a = "1"; // Converts to 1. May or may not throw an error (I'm
still on the fence).
$a = "blah"; // Current kosher unchanged.
weak int $a = "blah"; // Throws E_x error level.
strong int $a = "blah"; // Throws E_y error level.
Where E_y > E_x.
--Kris
On Tue, Feb 28, 2012 at 1:52 PM, John Crenshaw johncrenshaw@priacta.comwrote:
No, In the example given there's an error on int $a = "1". There should be
no error because this juggles fine.John Crenshaw
Priacta, inc.-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Tuesday, February 28, 2012 4:47 PM
To: Richard Lynch
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting@Richard That's fairly close to what I'm thinking, yes. But there seems
to be a diverse range of ideas bouncing around right now, so at present
it's all in flux.--Kris
I think this is the main reason for differentiating between "strong"
(or
whatever word is appropriate) and "weak." The developer may very
well want their script to blow-up in such a case.I believe I actually "get it" now...
You want 3 layers:
$a = "1"; //current kosher unchanged
weak int $a = "1"; // some E_x error level strong int $a = "1"; //
some E_y error level where E_y > E_xIs that a correct summation?
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=F
S9NLTNEEKWBE--
To unsubscribe,
visit: http://www.php.net/unsub.php
strong int $a = "1"; // Converts to 1. May or may not throw an error (I'm
still on the fence).
It this is an error, it is no longer PHP.
@Rick Though I'm not sure I'd agree with the overly broad "it is no longer
PHP" hyperbole, I think the basic point that it would be a significant
departure from the current model has merit. So ok, you've convinced me.
That example should not throw any errors. I'm officially no longer on the
fence with that. =)
--Kris
On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer vchkpw@developersdesk.comwrote:
strong int $a = "1"; // Converts to 1. May or may not throw an error (I'm
still on the fence).
It this is an error, it is no longer PHP.
On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer vchkpw@developersdesk.comwrote:
strong int $a = "1"; // Converts to 1. May or may not throw an error
(I'mstill on the fence).
It this is an error, it is no longer PHP.
@Rick Though I'm not sure I'd agree with the overly broad "it is no longer PHP" hyperbole, I think the basic point that it would be a significant departure from the current model has merit. So ok, you've convinced me.
That example should not throw any errors. I'm officially no longer on the fence with that. =)--Kris
OK, if we're all on the same page there, I think this means that there is no significant difference between the "strong int" and "weak int" in your proposal (the only remaining difference being the level of error raised when it cannot be converted, which IMO is not substantial enough to deserve a keyword.) I'd prefer to just pick one error level to use (E_RECOVERABLE_ERROR would be the most consistent) and keep everything simple.
John Crenshaw
Priacta, Inc.
I wouldn't mind that, though I'm concerned that it may not be sellable
because some people on here have expressed a strong opinion that this
shouldn't throw anything more than a notice or a warning at most, something
that I and others strongly disagree with. The logical approach, to me at
least, is to follow the example of include() and require(); i.e. they're
both identical except that one throws a scary error while the other one is
just a warning.
I'm fine with just throwing E_RECOVERABLE_ERROR, though I fear that may
alienate too many people for us to be able to get this through. Though
it's possible I might be overestimating that factor.
--Kris
On Tue, Feb 28, 2012 at 5:17 PM, John Crenshaw johncrenshaw@priacta.comwrote:
On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer <vchkpw@developersdesk.com
wrote:strong int $a = "1"; // Converts to 1. May or may not throw an error
(I'mstill on the fence).
It this is an error, it is no longer PHP.
@Rick Though I'm not sure I'd agree with the overly broad "it is no
longer PHP" hyperbole, I think the basic point that it would be a
significant departure from the current model has merit. So ok, you've
convinced me.
That example should not throw any errors. I'm officially no longer on the
fence with that. =)--Kris
OK, if we're all on the same page there, I think this means that there is
no significant difference between the "strong int" and "weak int" in your
proposal (the only remaining difference being the level of error raised
when it cannot be converted, which IMO is not substantial enough to deserve
a keyword.) I'd prefer to just pick one error level to use
(E_RECOVERABLE_ERROR would be the most consistent) and keep everything
simple.John Crenshaw
Priacta, Inc.
I would personally be inclined towards something simpler like E_NOTICE or E_WARNING, but current type hints all raise E_RECOVERABLE_ERROR. I think we should be consistent, and the consistency argument may make the difference.
There may be a strong case for changing the error level on all type hints to something simpler (or new, like E_TYPE), but I think that might be better to tackle that in a separate discussion.
John Crenshaw
Priacta, Inc.
From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Tuesday, February 28, 2012 8:40 PM
To: John Crenshaw
Cc: Rick WIdmer; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
I wouldn't mind that, though I'm concerned that it may not be sellable because some people on here have expressed a strong opinion that this shouldn't throw anything more than a notice or a warning at most, something that I and others strongly disagree with. The logical approach, to me at least, is to follow the example of include() and require(); i.e. they're both identical except that one throws a scary error while the other one is just a warning.
I'm fine with just throwing E_RECOVERABLE_ERROR, though I fear that may alienate too many people for us to be able to get this through. Though it's possible I might be overestimating that factor.
--Kris
On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer <vchkpw@developersdesk.commailto:vchkpw@developersdesk.com>wrote:
strong int $a = "1"; // Converts to 1. May or may not throw an error
(I'mstill on the fence).
It this is an error, it is no longer PHP.
@Rick Though I'm not sure I'd agree with the overly broad "it is no longer PHP" hyperbole, I think the basic point that it would be a significant departure from the current model has merit. So ok, you've convinced me.
That example should not throw any errors. I'm officially no longer on the fence with that. =)--Kris
OK, if we're all on the same page there, I think this means that there is no significant difference between the "strong int" and "weak int" in your proposal (the only remaining difference being the level of error raised when it cannot be converted, which IMO is not substantial enough to deserve a keyword.) I'd prefer to just pick one error level to use (E_RECOVERABLE_ERROR would be the most consistent) and keep everything simple.
John Crenshaw
Priacta, Inc.
Hi, John
I personally do not care about weak or strong variables at all ... I only
want what Arvids suggested last time:
test(1, 2); // 2;
test("1", 2); // 2
test("1aaa", 2); //E_NOTICEor E_TYPE and result 2
test(array(2), 2); //E_RECOVERABLE_ERROR- just like with array type
hint now.It's really what the most people want. Simple, easy to pick up (object
and array already have this) and is just optional.
I count myself as a part of most people in this statement ;)
I'm also quite fine with the current type-hints as you'd anyways get an
error if you try something like this:
function foo(SimpleClass $a) {
$a->getName();
}
foo("Test");
If you now get method called from an non-object or a message that you
have passed a value that's not compatible with SimpleClass ...
I'd like to split this discussion in parts:
- just type-hint in functions (as we have it with classes and arrays) or
bind a variable to a strict type?- should it then also be possible bind variables to a specific class
or interface?
- should it then also be possible bind variables to a specific class
- should we go for weak or strong types?
- the type-hint is also weak in one way because it accepts all that's
compatible with the given type.
- the type-hint is also weak in one way because it accepts all that's
Bye
Simon
2012/2/29 John Crenshaw johncrenshaw@priacta.com
I would personally be inclined towards something simpler like
E_NOTICEor
E_WARNING, but current type hints all raise E_RECOVERABLE_ERROR. I think we
should be consistent, and the consistency argument may make the difference.There may be a strong case for changing the error level on all type hints
to something simpler (or new, like E_TYPE), but I think that might be
better to tackle that in a separate discussion.John Crenshaw
Priacta, Inc.From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Tuesday, February 28, 2012 8:40 PM
To: John Crenshaw
Cc: Rick WIdmer; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hintingI wouldn't mind that, though I'm concerned that it may not be sellable
because some people on here have expressed a strong opinion that this
shouldn't throw anything more than a notice or a warning at most, something
that I and others strongly disagree with. The logical approach, to me at
least, is to follow the example of include() and require(); i.e. they're
both identical except that one throws a scary error while the other one is
just a warning.I'm fine with just throwing E_RECOVERABLE_ERROR, though I fear that may
alienate too many people for us to be able to get this through. Though
it's possible I might be overestimating that factor.--Kris
On Tue, Feb 28, 2012 at 5:17 PM, John Crenshaw <johncrenshaw@priacta.com
mailto:johncrenshaw@priacta.com> wrote:On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer <vchkpw@developersdesk.com
mailto:vchkpw@developersdesk.com>wrote:strong int $a = "1"; // Converts to 1. May or may not throw an error
(I'mstill on the fence).
It this is an error, it is no longer PHP.
@Rick Though I'm not sure I'd agree with the overly broad "it is no
longer PHP" hyperbole, I think the basic point that it would be a
significant departure from the current model has merit. So ok, you've
convinced me.
That example should not throw any errors. I'm officially no longer on the
fence with that. =)--Kris
OK, if we're all on the same page there, I think this means that there is
no significant difference between the "strong int" and "weak int" in your
proposal (the only remaining difference being the level of error raised
when it cannot be converted, which IMO is not substantial enough to deserve
a keyword.) I'd prefer to just pick one error level to use
(E_RECOVERABLE_ERROR would be the most consistent) and keep everything
simple.John Crenshaw
Priacta, Inc.
Hi,
We could even combine this with the following RFC:
https://wiki.php.net/rfc/object_cast_magic
If an integer is required and you pass an object, it first checks if this
object is castable to integer ;)
Bye
Simon
2012/2/29 Simon Schick simonsimcity@googlemail.com
Hi, John
I personally do not care about weak or strong variables at all ... I only
want what Arvids suggested last time:test(1, 2); // 2;
test("1", 2); // 2
test("1aaa", 2); //E_NOTICEor E_TYPE and result 2
test(array(2), 2); //E_RECOVERABLE_ERROR- just like with array type
hint now.It's really what the most people want. Simple, easy to pick up (object
and array already have this) and is just optional.I count myself as a part of most people in this statement ;)
I'm also quite fine with the current type-hints as you'd anyways get an
error if you try something like this:function foo(SimpleClass $a) {
$a->getName();
}foo("Test");
If you now get method called from an non-object or a message that you
have passed a value that's not compatible with SimpleClass ...I'd like to split this discussion in parts:
- just type-hint in functions (as we have it with classes and arrays)
or bind a variable to a strict type?
- should it then also be possible bind variables to a specific
class or interface?- should we go for weak or strong types?
- the type-hint is also weak in one way because it accepts all
that's compatible with the given type.Bye
Simon2012/2/29 John Crenshaw johncrenshaw@priacta.com
I would personally be inclined towards something simpler like
E_NOTICEor
E_WARNING, but current type hints all raise E_RECOVERABLE_ERROR. I think we
should be consistent, and the consistency argument may make the difference.There may be a strong case for changing the error level on all type hints
to something simpler (or new, like E_TYPE), but I think that might be
better to tackle that in a separate discussion.John Crenshaw
Priacta, Inc.From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Tuesday, February 28, 2012 8:40 PM
To: John Crenshaw
Cc: Rick WIdmer; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hintingI wouldn't mind that, though I'm concerned that it may not be sellable
because some people on here have expressed a strong opinion that this
shouldn't throw anything more than a notice or a warning at most, something
that I and others strongly disagree with. The logical approach, to me at
least, is to follow the example of include() and require(); i.e. they're
both identical except that one throws a scary error while the other one is
just a warning.I'm fine with just throwing E_RECOVERABLE_ERROR, though I fear that may
alienate too many people for us to be able to get this through. Though
it's possible I might be overestimating that factor.--Kris
On Tue, Feb 28, 2012 at 5:17 PM, John Crenshaw <johncrenshaw@priacta.com
mailto:johncrenshaw@priacta.com> wrote:On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer <vchkpw@developersdesk.com
mailto:vchkpw@developersdesk.com>wrote:strong int $a = "1"; // Converts to 1. May or may not throw an error
(I'mstill on the fence).
It this is an error, it is no longer PHP.
@Rick Though I'm not sure I'd agree with the overly broad "it is no
longer PHP" hyperbole, I think the basic point that it would be a
significant departure from the current model has merit. So ok, you've
convinced me.
That example should not throw any errors. I'm officially no longer on
the fence with that. =)--Kris
OK, if we're all on the same page there, I think this means that there is
no significant difference between the "strong int" and "weak int" in your
proposal (the only remaining difference being the level of error raised
when it cannot be converted, which IMO is not substantial enough to deserve
a keyword.) I'd prefer to just pick one error level to use
(E_RECOVERABLE_ERROR would be the most consistent) and keep everything
simple.John Crenshaw
Priacta, Inc.
Combining different things into one big RFC is not a good idea. It's
hard to develop and test the work it it's in one big chunk.
Decomposition makes it much easier. Type hinting has to have it's own
RFC.
Besides - someone can be willing to do type hinting patch and don't
want to do the object_cast_magic one.
And thanks for the support :)
2012/2/29 Simon Schick simonsimcity@googlemail.com:
Hi,
We could even combine this with the following RFC:
https://wiki.php.net/rfc/object_cast_magicIf an integer is required and you pass an object, it first checks if this
object is castable to integer ;)Bye
Simon2012/2/29 Simon Schick simonsimcity@googlemail.com
Hi, John
I personally do not care about weak or strong variables at all ... I only
want what Arvids suggested last time:test(1, 2); // 2;
test("1", 2); // 2
test("1aaa", 2); //E_NOTICEor E_TYPE and result 2
test(array(2), 2); //E_RECOVERABLE_ERROR- just like with array type
hint now.It's really what the most people want. Simple, easy to pick up (object
and array already have this) and is just optional.I count myself as a part of most people in this statement ;)
I'm also quite fine with the current type-hints as you'd anyways get an
error if you try something like this:function foo(SimpleClass $a) {
$a->getName();
}foo("Test");
If you now get method called from an non-object or a message that you
have passed a value that's not compatible with SimpleClass ...I'd like to split this discussion in parts:
- just type-hint in functions (as we have it with classes and arrays)
or bind a variable to a strict type?
- should it then also be possible bind variables to a specific
class or interface?
- should we go for weak or strong types?
- the type-hint is also weak in one way because it accepts all
that's compatible with the given type.Bye
Simon2012/2/29 John Crenshaw johncrenshaw@priacta.com
I would personally be inclined towards something simpler like
E_NOTICEor
E_WARNING, but current type hints all raise E_RECOVERABLE_ERROR. I think we
should be consistent, and the consistency argument may make the difference.There may be a strong case for changing the error level on all type hints
to something simpler (or new, like E_TYPE), but I think that might be
better to tackle that in a separate discussion.John Crenshaw
Priacta, Inc.From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Tuesday, February 28, 2012 8:40 PM
To: John Crenshaw
Cc: Rick WIdmer; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hintingI wouldn't mind that, though I'm concerned that it may not be sellable
because some people on here have expressed a strong opinion that this
shouldn't throw anything more than a notice or a warning at most, something
that I and others strongly disagree with. The logical approach, to me at
least, is to follow the example of include() and require(); i.e. they're
both identical except that one throws a scary error while the other one is
just a warning.I'm fine with just throwing E_RECOVERABLE_ERROR, though I fear that may
alienate too many people for us to be able to get this through. Though
it's possible I might be overestimating that factor.--Kris
On Tue, Feb 28, 2012 at 5:17 PM, John Crenshaw <johncrenshaw@priacta.com
mailto:johncrenshaw@priacta.com> wrote:On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer <vchkpw@developersdesk.com
mailto:vchkpw@developersdesk.com>wrote:strong int $a = "1"; // Converts to 1. May or may not throw an error
(I'mstill on the fence).
It this is an error, it is no longer PHP.
@Rick Though I'm not sure I'd agree with the overly broad "it is no
longer PHP" hyperbole, I think the basic point that it would be a
significant departure from the current model has merit. So ok, you've
convinced me.
That example should not throw any errors. I'm officially no longer on
the fence with that. =)--Kris
OK, if we're all on the same page there, I think this means that there is
no significant difference between the "strong int" and "weak int" in your
proposal (the only remaining difference being the level of error raised
when it cannot be converted, which IMO is not substantial enough to deserve
a keyword.) I'd prefer to just pick one error level to use
(E_RECOVERABLE_ERROR would be the most consistent) and keep everything
simple.John Crenshaw
Priacta, Inc.
Hi, Arvids
I did not meant to putt all in one big RFC but more to think about the
connection between these two while developing.
Bye
Simon
2012/2/29 Arvids Godjuks arvids.godjuks@gmail.com
Combining different things into one big RFC is not a good idea. It's
hard to develop and test the work it it's in one big chunk.
Decomposition makes it much easier. Type hinting has to have it's own
RFC.
Besides - someone can be willing to do type hinting patch and don't
want to do the object_cast_magic one.And thanks for the support :)
2012/2/29 Simon Schick simonsimcity@googlemail.com:
Hi,
We could even combine this with the following RFC:
https://wiki.php.net/rfc/object_cast_magicIf an integer is required and you pass an object, it first checks if this
object is castable to integer ;)Bye
Simon2012/2/29 Simon Schick simonsimcity@googlemail.com
Hi, John
I personally do not care about weak or strong variables at all ... I
only
want what Arvids suggested last time:test(1, 2); // 2;
test("1", 2); // 2
test("1aaa", 2); //E_NOTICEor E_TYPE and result 2
test(array(2), 2); //E_RECOVERABLE_ERROR- just like with array type
hint now.It's really what the most people want. Simple, easy to pick up (object
and array already have this) and is just optional.I count myself as a part of most people in this statement ;)
I'm also quite fine with the current type-hints as you'd anyways get an
error if you try something like this:function foo(SimpleClass $a) {
$a->getName();
}foo("Test");
If you now get method called from an non-object or a message that you
have passed a value that's not compatible with SimpleClass ...I'd like to split this discussion in parts:
- just type-hint in functions (as we have it with classes and arrays)
or bind a variable to a strict type?
- should it then also be possible bind variables to a specific
class or interface?- should we go for weak or strong types?
- the type-hint is also weak in one way because it accepts all
that's compatible with the given type.Bye
Simon2012/2/29 John Crenshaw johncrenshaw@priacta.com
I would personally be inclined towards something simpler like
E_NOTICE
or
E_WARNING, but current type hints all raise E_RECOVERABLE_ERROR. I
think we
should be consistent, and the consistency argument may make the
difference.There may be a strong case for changing the error level on all type
hints
to something simpler (or new, like E_TYPE), but I think that might be
better to tackle that in a separate discussion.John Crenshaw
Priacta, Inc.From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Tuesday, February 28, 2012 8:40 PM
To: John Crenshaw
Cc: Rick WIdmer; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hintingI wouldn't mind that, though I'm concerned that it may not be sellable
because some people on here have expressed a strong opinion that this
shouldn't throw anything more than a notice or a warning at most,
something
that I and others strongly disagree with. The logical approach, to me
at
least, is to follow the example of include() and require(); i.e.
they're
both identical except that one throws a scary error while the other
one is
just a warning.I'm fine with just throwing E_RECOVERABLE_ERROR, though I fear that may
alienate too many people for us to be able to get this through. Though
it's possible I might be overestimating that factor.--Kris
On Tue, Feb 28, 2012 at 5:17 PM, John Crenshaw <
johncrenshaw@priacta.com
mailto:johncrenshaw@priacta.com> wrote:On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer <
vchkpw@developersdesk.com
mailto:vchkpw@developersdesk.com>wrote:strong int $a = "1"; // Converts to 1. May or may not throw an
error
(I'mstill on the fence).
It this is an error, it is no longer PHP.
@Rick Though I'm not sure I'd agree with the overly broad "it is no
longer PHP" hyperbole, I think the basic point that it would be a
significant departure from the current model has merit. So ok, you've
convinced me.
That example should not throw any errors. I'm officially no longer on
the fence with that. =)--Kris
OK, if we're all on the same page there, I think this means that there
is
no significant difference between the "strong int" and "weak int" in
your
proposal (the only remaining difference being the level of error raised
when it cannot be converted, which IMO is not substantial enough to
deserve
a keyword.) I'd prefer to just pick one error level to use
(E_RECOVERABLE_ERROR would be the most consistent) and keep everything
simple.John Crenshaw
Priacta, Inc.
I agree with the notion of typing in function arguments, though I'm not a
fan of this particular approach. Specifically, I don't like the idea of
"1aaa" throwing one kind of error (E_NOTICE) and array($whatever) throwing
another kind of error. They should both throw the same error because
they're both incompatible types; i.e. "1" == 1 but "1aaa" != 1. I don't
like the idea of saying that one incompatible type is "worse" than
another. I just don't see any value in that and it ultimately just makes
things more confusing and complicated than they need to be for the end-user.
Instead, they should both throw the same kind of error. Whether it's just
E_RECOVERABLE_ERROR or we give the developer a choice by having
strong/weak, I'm fine either way (though I think the second approach adds
more flexibility without any practical drawbacks).
And again, let's avoid using phrases like "most people". I'll let
Wikipedia elaborate on why:
http://en.wikipedia.org/wiki/Weasel_word
--Kris
On Wed, Feb 29, 2012 at 2:26 AM, Simon Schick
simonsimcity@googlemail.comwrote:
Hi, Arvids
I did not meant to putt all in one big RFC but more to think about the
connection between these two while developing.Bye
Simon2012/2/29 Arvids Godjuks arvids.godjuks@gmail.com
Combining different things into one big RFC is not a good idea. It's
hard to develop and test the work it it's in one big chunk.
Decomposition makes it much easier. Type hinting has to have it's own
RFC.
Besides - someone can be willing to do type hinting patch and don't
want to do the object_cast_magic one.And thanks for the support :)
2012/2/29 Simon Schick simonsimcity@googlemail.com:
Hi,
We could even combine this with the following RFC:
https://wiki.php.net/rfc/object_cast_magicIf an integer is required and you pass an object, it first checks if
this
object is castable to integer ;)Bye
Simon2012/2/29 Simon Schick simonsimcity@googlemail.com
Hi, John
I personally do not care about weak or strong variables at all ... I
only
want what Arvids suggested last time:test(1, 2); // 2;
test("1", 2); // 2
test("1aaa", 2); //E_NOTICEor E_TYPE and result 2
test(array(2), 2); //E_RECOVERABLE_ERROR- just like with array
type
hint now.It's really what the most people want. Simple, easy to pick up
(object
and array already have this) and is just optional.I count myself as a part of most people in this statement ;)
I'm also quite fine with the current type-hints as you'd anyways get
an
error if you try something like this:function foo(SimpleClass $a) {
$a->getName();
}foo("Test");
If you now get method called from an non-object or a message that
you
have passed a value that's not compatible with SimpleClass ...I'd like to split this discussion in parts:
- just type-hint in functions (as we have it with classes and
arrays)
or bind a variable to a strict type?
- should it then also be possible bind variables to a specific
class or interface?- should we go for weak or strong types?
- the type-hint is also weak in one way because it accepts all
that's compatible with the given type.Bye
Simon2012/2/29 John Crenshaw johncrenshaw@priacta.com
I would personally be inclined towards something simpler like
E_NOTICE
or
E_WARNING, but current type hints all raise E_RECOVERABLE_ERROR. I
think we
should be consistent, and the consistency argument may make the
difference.There may be a strong case for changing the error level on all type
hints
to something simpler (or new, like E_TYPE), but I think that might be
better to tackle that in a separate discussion.John Crenshaw
Priacta, Inc.From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Tuesday, February 28, 2012 8:40 PM
To: John Crenshaw
Cc: Rick WIdmer; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hintingI wouldn't mind that, though I'm concerned that it may not be
sellable
because some people on here have expressed a strong opinion that this
shouldn't throw anything more than a notice or a warning at most,
something
that I and others strongly disagree with. The logical approach, to
me
at
least, is to follow the example of include() and require(); i.e.
they're
both identical except that one throws a scary error while the other
one is
just a warning.I'm fine with just throwing E_RECOVERABLE_ERROR, though I fear that
may
alienate too many people for us to be able to get this through.
Though
it's possible I might be overestimating that factor.--Kris
On Tue, Feb 28, 2012 at 5:17 PM, John Crenshaw <
johncrenshaw@priacta.com
mailto:johncrenshaw@priacta.com> wrote:On Tue, Feb 28, 2012 at 3:03 PM, Rick WIdmer <
vchkpw@developersdesk.com
mailto:vchkpw@developersdesk.com>wrote:strong int $a = "1"; // Converts to 1. May or may not throw an
error
(I'mstill on the fence).
It this is an error, it is no longer PHP.
@Rick Though I'm not sure I'd agree with the overly broad "it is no
longer PHP" hyperbole, I think the basic point that it would be a
significant departure from the current model has merit. So ok,
you've
convinced me.
That example should not throw any errors. I'm officially no longer
on
the fence with that. =)--Kris
OK, if we're all on the same page there, I think this means that
there
is
no significant difference between the "strong int" and "weak int" in
your
proposal (the only remaining difference being the level of error
raised
when it cannot be converted, which IMO is not substantial enough to
deserve
a keyword.) I'd prefer to just pick one error level to use
(E_RECOVERABLE_ERROR would be the most consistent) and keep
everything
simple.John Crenshaw
Priacta, Inc.
I agree with Simon on this:
I'd like to split this discussion in parts:
- just type-hint in functions (as we have it with classes and arrays) or
bind a variable to a strict type?
- should it then also be possible bind variables to a specific class
or interface?
- should we go for weak or strong types?
- the type-hint is also weak in one way because it accepts all that's
compatible with the given type.
These make a lot more sense in terms of discussion and those who don't
agree on having strong type implemented in the language core would
probably see value in type-hinting like we have with classes & arrays
(even if here we enter again in a strong vs. weak discussion).
I for once agree it can be useful to have type-hinting for the other
types, including throwing an error if there's loss of data in
conversion. Although I'm not so sure about having strong types...
Regards,
Daniel Macedo
Agreed. If conversion can occur without data loss (that is, if the
value being assigned is == the value that actually IS assigned) then
no error should occur.
So
int $a = "1"; // no error. 1 == "1" so who cares?
int $a = 'House'; // error 0 != 'House', so this is a problem.
Again, errors should only raise if the final value != source value.
strong int $a = "1"; // Converts to 1. May or may not throw an error (I'm
still on the fence).It this is an error, it is no longer PHP.
+1 on that.
However, I believe the coder should also have the option of determining
whether this should be recoverable or not, just like they have a choice
with regard to using "include" or "require" (one fails gracefully, the
other terminates execution).
That's where I think strong/weak could be very useful. Here's how I would
do it:
weak int $a = "House"; // Throws E_WARNING
strong int $a = "House"; // Throws E_RECOVERABLE_ERROR
In both cases, the error can be caught, which would mirror the flexibility
in languages like C#. However, if the weak one isn't caught, the warning
is thrown but the script proceeds as normal. If the strong one isn't
caught, the script will terminate as if it was an E_ERROR.
I think this would be the most sensible approach in terms of balancing
simplicity and flexibility.
--Kris
On Tue, Feb 28, 2012 at 3:08 PM, Michael Morris dmgx.michael@gmail.comwrote:
Agreed. If conversion can occur without data loss (that is, if the
value being assigned is == the value that actually IS assigned) then
no error should occur.So
int $a = "1"; // no error. 1 == "1" so who cares?
int $a = 'House'; // error 0 != 'House', so this is a problem.Again, errors should only raise if the final value != source value.
On Tue, Feb 28, 2012 at 6:03 PM, Rick WIdmer vchkpw@developersdesk.com
wrote:strong int $a = "1"; // Converts to 1. May or may not throw an error
(I'm
still on the fence).It this is an error, it is no longer PHP.
Some cases I would find interesting to be explained:
(using 'streak' for strong and/or weak, feel free to separate the two)
streak int $i = 123.456; //Common idiom for floor()
streak int $i = "123.456"; //In contrast to previous
streak int $i = "1 "; //value="1 " is ridiculously common HTML
It's all well and good to say that any loss of data is "bad" and to
raise some E_* for it, but there are some idioms so common that feel
"wrong" as I consider them...
If everyone "for" the new type hinting/forcing can reach consensus on
these sorts of cases, it would help clarify any RFCs a bit, I think
wrt E_RECOVERABLE_ERROR vs E_WARNING
If current type hinting raises E_RECOVERABLE_ERROR, I have no
objection to following that lead, with the explicit caveat that a
change to the existing type-hinting to E_WARNING, as unlikely as that
seems, would pull the new "streak" with it.
I don't even object to using E_ERROR for the "strong" variant, if that
passes review, really, since "strong" is, errr, strong. :-)
Anybody who doesn't like the E_* can re-define them in a custom error
handler anyway, though allowing PHP to continue after E_ERROR is like
playing russian roulette...
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
@Richard I think you made a very good point. Should we treat a float =>
int mismatch the same as we would a string => int mismatch, or should the
former fail more gracefully? I can see good arguments for both.
--Kris
Some cases I would find interesting to be explained:
(using 'streak' for strong and/or weak, feel free to separate the two)
streak int $i = 123.456; //Common idiom for
floor()
streak int $i = "123.456"; //In contrast to previous
streak int $i = "1 "; //value="1 " is ridiculously common HTMLIt's all well and good to say that any loss of data is "bad" and to
raise some E_* for it, but there are some idioms so common that feel
"wrong" as I consider them...If everyone "for" the new type hinting/forcing can reach consensus on
these sorts of cases, it would help clarify any RFCs a bit, I thinkwrt
E_RECOVERABLE_ERRORvsE_WARNINGIf current type hinting raises E_RECOVERABLE_ERROR, I have no
objection to following that lead, with the explicit caveat that a
change to the existing type-hinting to E_WARNING, as unlikely as that
seems, would pull the new "streak" with it.I don't even object to using
E_ERRORfor the "strong" variant, if that
passes review, really, since "strong" is, errr, strong. :-)Anybody who doesn't like the E_* can re-define them in a custom error
handler anyway, though allowing PHP to continue afterE_ERRORis like
playing russian roulette...--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
Now that I think of it, this would probably be a good argument for
differentiating between strong and weak. Looking back to my previous
comment, it probably would be best to have it behave the same regardless of
what the incompatible type is. But in the case where a float might sneak
its way into an int, the developer might decide that going with a weak type
would make it more flexible (though if it was me, I'd just do a round or
leave it a mixed type lol).
--Kris
@Richard I think you made a very good point. Should we treat a float =>
int mismatch the same as we would a string => int mismatch, or should the
former fail more gracefully? I can see good arguments for both.--Kris
Some cases I would find interesting to be explained:
(using 'streak' for strong and/or weak, feel free to separate the two)
streak int $i = 123.456; //Common idiom for
floor()
streak int $i = "123.456"; //In contrast to previous
streak int $i = "1 "; //value="1 " is ridiculously common HTMLIt's all well and good to say that any loss of data is "bad" and to
raise some E_* for it, but there are some idioms so common that feel
"wrong" as I consider them...If everyone "for" the new type hinting/forcing can reach consensus on
these sorts of cases, it would help clarify any RFCs a bit, I thinkwrt
E_RECOVERABLE_ERRORvsE_WARNINGIf current type hinting raises E_RECOVERABLE_ERROR, I have no
objection to following that lead, with the explicit caveat that a
change to the existing type-hinting to E_WARNING, as unlikely as that
seems, would pull the new "streak" with it.I don't even object to using
E_ERRORfor the "strong" variant, if that
passes review, really, since "strong" is, errr, strong. :-)Anybody who doesn't like the E_* can re-define them in a custom error
handler anyway, though allowing PHP to continue afterE_ERRORis like
playing russian roulette...--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
Hi, Kris
I don't think we have to care about scripts that are written right now if
we're talking about throwing an E_RECOVERABLE_ERROR or E_WARNING because
this feature is completely new. But I like the idea to have all type-hint
failures ending up the same way.
I personally would keep the error-messages for classes and arrays as they
are right now and do the same error in case the given value is not
compatible to the expected type.
Not compatible means that data gets lost after converting the data into the
other data-type.
Lets have an example:
function foo(integer $i) {
// do something
}
foo(true); // Even if Boolean is a lower type than int, it can be easily
casted to an int. It's equivalent to 1.
foo("1"); // wont throw an error because the transformation into an integer
is loose-less
foo(2.5); // Throws an E_RECOVERABLE_ERROR because its a float, but an
integer is required here.
foo("horse"); // Throws an E_RECOVERABLE_ERROR because if you transform
"horse" into a float, it's 1 and that's not equal to the string anymore.
I personally would treat float - int miss matches the same way as all other
stuff, because it cannot be converted loose-less.
And if the Object-cast-stuff comes through, we have to think about this in
addition:
https://wiki.php.net/rfc/object_cast_magic
class MyInteger {
public function __castTo(string $type) {
if ($type === "integer")
return 5;
}
}
function foo(integer $i) {
// do something
}
foo(new MyInteger()); // Even if this is an object - it's cast-able to an
integer and therefore should be valid
But this is just in case the RFC gets through ;) We don't have to think
that much about it now - just keep it in mind.
Bye
Simon
2012/2/29 Kris Craig kris.craig@gmail.com
Now that I think of it, this would probably be a good argument for
differentiating between strong and weak. Looking back to my previous
comment, it probably would be best to have it behave the same regardless of
what the incompatible type is. But in the case where a float might sneak
its way into an int, the developer might decide that going with a weak type
would make it more flexible (though if it was me, I'd just do a round or
leave it a mixed type lol).--Kris
@Richard I think you made a very good point. Should we treat a float =>
int mismatch the same as we would a string => int mismatch, or should the
former fail more gracefully? I can see good arguments for both.--Kris
Some cases I would find interesting to be explained:
(using 'streak' for strong and/or weak, feel free to separate the two)
streak int $i = 123.456; //Common idiom for
floor()
streak int $i = "123.456"; //In contrast to previous
streak int $i = "1 "; //value="1 " is ridiculously common HTMLIt's all well and good to say that any loss of data is "bad" and to
raise some E_* for it, but there are some idioms so common that feel
"wrong" as I consider them...If everyone "for" the new type hinting/forcing can reach consensus on
these sorts of cases, it would help clarify any RFCs a bit, I thinkwrt
E_RECOVERABLE_ERRORvsE_WARNINGIf current type hinting raises E_RECOVERABLE_ERROR, I have no
objection to following that lead, with the explicit caveat that a
change to the existing type-hinting to E_WARNING, as unlikely as that
seems, would pull the new "streak" with it.I don't even object to using
E_ERRORfor the "strong" variant, if that
passes review, really, since "strong" is, errr, strong. :-)Anybody who doesn't like the E_* can re-define them in a custom error
handler anyway, though allowing PHP to continue afterE_ERRORis like
playing russian roulette...--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
@Simon Agreed. That's pretty much what I'm thinking it should look like.
With booleans, I think you have a good point. If 1 or 0 is passed to a
bool, I'd say that should be fine without an error. If you were to pass a
2, though (you insolent bastard!), then it would throw the error.
I think we're getting pretty close to having enough to write an RFC for
this. I'll go ahead and create one after a little more discussion goes
around.
--Kris
On Wed, Feb 29, 2012 at 11:50 AM, Simon Schick
simonsimcity@googlemail.comwrote:
Hi, Kris
I don't think we have to care about scripts that are written right now if
we're talking about throwing anE_RECOVERABLE_ERRORorE_WARNINGbecause
this feature is completely new. But I like the idea to have all type-hint
failures ending up the same way.I personally would keep the error-messages for classes and arrays as they
are right now and do the same error in case the given value is not
compatible to the expected type.
Not compatible means that data gets lost after converting the data into
the other data-type.Lets have an example:
function foo(integer $i) {
// do something
}foo(true); // Even if Boolean is a lower type than int, it can be easily
casted to an int. It's equivalent to 1.
foo("1"); // wont throw an error because the transformation into an
integer is loose-less
foo(2.5); // Throws anE_RECOVERABLE_ERRORbecause its a float, but an
integer is required here.
foo("horse"); // Throws anE_RECOVERABLE_ERRORbecause if you transform
"horse" into a float, it's 1 and that's not equal to the string anymore.I personally would treat float - int miss matches the same way as all
other stuff, because it cannot be converted loose-less.And if the Object-cast-stuff comes through, we have to think about this in
addition:
https://wiki.php.net/rfc/object_cast_magicclass MyInteger {
public function __castTo(string $type) {
if ($type === "integer")
return 5;
}
}function foo(integer $i) {
// do something
}foo(new MyInteger()); // Even if this is an object - it's cast-able to an
integer and therefore should be validBut this is just in case the RFC gets through ;) We don't have to think
that much about it now - just keep it in mind.Bye
Simon2012/2/29 Kris Craig kris.craig@gmail.com
Now that I think of it, this would probably be a good argument for
differentiating between strong and weak. Looking back to my previous
comment, it probably would be best to have it behave the same regardless
of
what the incompatible type is. But in the case where a float might sneak
its way into an int, the developer might decide that going with a weak
type
would make it more flexible (though if it was me, I'd just do a round or
leave it a mixed type lol).--Kris
On Wed, Feb 29, 2012 at 11:09 AM, Kris Craig kris.craig@gmail.com
wrote:@Richard I think you made a very good point. Should we treat a float =>
int mismatch the same as we would a string => int mismatch, or should
the
former fail more gracefully? I can see good arguments for both.--Kris
Some cases I would find interesting to be explained:
(using 'streak' for strong and/or weak, feel free to separate the two)
streak int $i = 123.456; //Common idiom for
floor()
streak int $i = "123.456"; //In contrast to previous
streak int $i = "1 "; //value="1 " is ridiculously common HTMLIt's all well and good to say that any loss of data is "bad" and to
raise some E_* for it, but there are some idioms so common that feel
"wrong" as I consider them...If everyone "for" the new type hinting/forcing can reach consensus on
these sorts of cases, it would help clarify any RFCs a bit, I thinkwrt
E_RECOVERABLE_ERRORvsE_WARNINGIf current type hinting raises E_RECOVERABLE_ERROR, I have no
objection to following that lead, with the explicit caveat that a
change to the existing type-hinting to E_WARNING, as unlikely as that
seems, would pull the new "streak" with it.I don't even object to using
E_ERRORfor the "strong" variant, if that
passes review, really, since "strong" is, errr, strong. :-)Anybody who doesn't like the E_* can re-define them in a custom error
handler anyway, though allowing PHP to continue afterE_ERRORis like
playing russian roulette...--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
And here's a thought: I could structure the RFC so that the voting will
have 3 choices: Yes with strong/weak differentiation, yes without
strong/weak, or no. However, the voting RFC doesn't cover how the tally
should be calculated in such a circumstance. For example, let's say we had
8 votes yes with differentiation, 2 votes yes without differentiation, and
5 votes no. If we tally the two "yes" columns, it's 10 - 5, which would be
the required 2/3 majority. However, how would we calculate the mandate on
differentiation? Among those who voted yes, there's a clear 8 - 2 (80%)
majority in favor of it. But if you count the no votes as being no to
differentiation and add them to the total, it suddenly becomes 8 - 7, which
falls short of the 2/3 majority. An argument could be made that these
people who voted no would not want differentiation, but another argument
could be made that; while they don't like the idea, if it does happen
they'd rather have it differentiated than not. In other words, determining
voter intent from that group would be difficult and thus only tallying
among the yes votes would make sense. Both arguments would have about
equal merit I think
The voting RFC does allow for different "options" in the vote, but it does
not elaborate on this. We could break the "no" group into two as well,
though that could make things a bit too confusing.
Since there's presently no clear procedure on this (at least none that I'm
aware of), what are your thoughts on this? I do believe the two should be
in the same vote since they're pretty integral to one another, but I'm not
sure how best to do that while maintaining accurate results without making
it too complicated.
--Kris
@Simon Agreed. That's pretty much what I'm thinking it should look like.
With booleans, I think you have a good point. If 1 or 0 is passed to a
bool, I'd say that should be fine without an error. If you were to pass a
2, though (you insolent bastard!), then it would throw the error.I think we're getting pretty close to having enough to write an RFC for
this. I'll go ahead and create one after a little more discussion goes
around.--Kris
On Wed, Feb 29, 2012 at 11:50 AM, Simon Schick <
simonsimcity@googlemail.com> wrote:Hi, Kris
I don't think we have to care about scripts that are written right now if
we're talking about throwing anE_RECOVERABLE_ERRORorE_WARNINGbecause
this feature is completely new. But I like the idea to have all type-hint
failures ending up the same way.I personally would keep the error-messages for classes and arrays as they
are right now and do the same error in case the given value is not
compatible to the expected type.
Not compatible means that data gets lost after converting the data into
the other data-type.Lets have an example:
function foo(integer $i) {
// do something
}foo(true); // Even if Boolean is a lower type than int, it can be easily
casted to an int. It's equivalent to 1.
foo("1"); // wont throw an error because the transformation into an
integer is loose-less
foo(2.5); // Throws anE_RECOVERABLE_ERRORbecause its a float, but an
integer is required here.
foo("horse"); // Throws anE_RECOVERABLE_ERRORbecause if you transform
"horse" into a float, it's 1 and that's not equal to the string anymore.I personally would treat float - int miss matches the same way as all
other stuff, because it cannot be converted loose-less.And if the Object-cast-stuff comes through, we have to think about this
in addition:
https://wiki.php.net/rfc/object_cast_magicclass MyInteger {
public function __castTo(string $type) {
if ($type === "integer")
return 5;
}
}function foo(integer $i) {
// do something
}foo(new MyInteger()); // Even if this is an object - it's cast-able to
an integer and therefore should be validBut this is just in case the RFC gets through ;) We don't have to think
that much about it now - just keep it in mind.Bye
Simon2012/2/29 Kris Craig kris.craig@gmail.com
Now that I think of it, this would probably be a good argument for
differentiating between strong and weak. Looking back to my previous
comment, it probably would be best to have it behave the same regardless
of
what the incompatible type is. But in the case where a float might sneak
its way into an int, the developer might decide that going with a weak
type
would make it more flexible (though if it was me, I'd just do a round or
leave it a mixed type lol).--Kris
On Wed, Feb 29, 2012 at 11:09 AM, Kris Craig kris.craig@gmail.com
wrote:@Richard I think you made a very good point. Should we treat a float
=>
int mismatch the same as we would a string => int mismatch, or should
the
former fail more gracefully? I can see good arguments for both.--Kris
Some cases I would find interesting to be explained:
(using 'streak' for strong and/or weak, feel free to separate the two)
streak int $i = 123.456; //Common idiom for
floor()
streak int $i = "123.456"; //In contrast to previous
streak int $i = "1 "; //value="1 " is ridiculously common HTMLIt's all well and good to say that any loss of data is "bad" and to
raise some E_* for it, but there are some idioms so common that feel
"wrong" as I consider them...If everyone "for" the new type hinting/forcing can reach consensus on
these sorts of cases, it would help clarify any RFCs a bit, I thinkwrt
E_RECOVERABLE_ERRORvsE_WARNINGIf current type hinting raises E_RECOVERABLE_ERROR, I have no
objection to following that lead, with the explicit caveat that a
change to the existing type-hinting to E_WARNING, as unlikely as that
seems, would pull the new "streak" with it.I don't even object to using
E_ERRORfor the "strong" variant, if that
passes review, really, since "strong" is, errr, strong. :-)Anybody who doesn't like the E_* can re-define them in a custom error
handler anyway, though allowing PHP to continue afterE_ERRORis like
playing russian roulette...--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
Hi, Kris
As we have some RFCs around that we should update them I think.
In my opinion we should split them up into 3 RFCs (and one grouping RFC):
Weak and strong type-checks (whatever that in detail means) should be
discussed in one single RFC. The option1 in the existing one is pretty
close to what I expect it to be - but why should f.e. "12abc" be a valid
integer? As said - we should update that.
https://wiki.php.net/rfc/typecheckingstrictandweak
Split the following RFC into two RFCs. Parameter type-hint and return
type-hint:
https://wiki.php.net/rfc/typehint
Until now we have two RFCs for return type-hint that should also be
combined. Add the information from the last mentioned here as well:
https://wiki.php.net/rfc/returntypehint2
https://wiki.php.net/rfc/returntypehint
And finally update the grouping-RFC:
https://wiki.php.net/rfc/typechecking
The RFCs for parameter- and return-type-hint should not contain the
definition of strict or weak type-hints.
After all three RFCs have been voted by a bunch of people we can write down
a RFC for a combination - f.e. how it should look like to have weak
function type-hinting or strong return type-hinting.
So .. here's quite a lot of work to do to gather the people who wrote these
RFCs and let their ideas float into one specific definition with several
options how to implement them.
Bye
Simon
2012/2/29 Kris Craig kris.craig@gmail.com
And here's a thought: I could structure the RFC so that the voting will
have 3 choices: Yes with strong/weak differentiation, yes without
strong/weak, or no. However, the voting RFC doesn't cover how the tally
should be calculated in such a circumstance. For example, let's say we had
8 votes yes with differentiation, 2 votes yes without differentiation, and
5 votes no. If we tally the two "yes" columns, it's 10 - 5, which would be
the required 2/3 majority. However, how would we calculate the mandate on
differentiation? Among those who voted yes, there's a clear 8 - 2 (80%)
majority in favor of it. But if you count the no votes as being no to
differentiation and add them to the total, it suddenly becomes 8 - 7, which
falls short of the 2/3 majority. An argument could be made that these
people who voted no would not want differentiation, but another argument
could be made that; while they don't like the idea, if it does happen
they'd rather have it differentiated than not. In other words, determining
voter intent from that group would be difficult and thus only tallying
among the yes votes would make sense. Both arguments would have about
equal merit I thinkThe voting RFC does allow for different "options" in the vote, but it does
not elaborate on this. We could break the "no" group into two as well,
though that could make things a bit too confusing.Since there's presently no clear procedure on this (at least none that I'm
aware of), what are your thoughts on this? I do believe the two should be
in the same vote since they're pretty integral to one another, but I'm not
sure how best to do that while maintaining accurate results without making
it too complicated.--Kris
@Simon Agreed. That's pretty much what I'm thinking it should look like.
With booleans, I think you have a good point. If 1 or 0 is passed to a
bool, I'd say that should be fine without an error. If you were to pass a
2, though (you insolent bastard!), then it would throw the error.I think we're getting pretty close to having enough to write an RFC for
this. I'll go ahead and create one after a little more discussion goes
around.--Kris
On Wed, Feb 29, 2012 at 11:50 AM, Simon Schick <
simonsimcity@googlemail.com> wrote:Hi, Kris
I don't think we have to care about scripts that are written right now
if we're talking about throwing anE_RECOVERABLE_ERRORorE_WARNINGbecause
this feature is completely new. But I like the idea to have all type-hint
failures ending up the same way.I personally would keep the error-messages for classes and arrays as
they are right now and do the same error in case the given value is not
compatible to the expected type.
Not compatible means that data gets lost after converting the data into
the other data-type.Lets have an example:
function foo(integer $i) {
// do something
}foo(true); // Even if Boolean is a lower type than int, it can be easily
casted to an int. It's equivalent to 1.
foo("1"); // wont throw an error because the transformation into an
integer is loose-less
foo(2.5); // Throws anE_RECOVERABLE_ERRORbecause its a float, but an
integer is required here.
foo("horse"); // Throws anE_RECOVERABLE_ERRORbecause if you transform
"horse" into a float, it's 1 and that's not equal to the string anymore.I personally would treat float - int miss matches the same way as all
other stuff, because it cannot be converted loose-less.And if the Object-cast-stuff comes through, we have to think about this
in addition:
https://wiki.php.net/rfc/object_cast_magicclass MyInteger {
public function __castTo(string $type) {
if ($type === "integer")
return 5;
}
}function foo(integer $i) {
// do something
}foo(new MyInteger()); // Even if this is an object - it's cast-able to
an integer and therefore should be validBut this is just in case the RFC gets through ;) We don't have to think
that much about it now - just keep it in mind.Bye
Simon2012/2/29 Kris Craig kris.craig@gmail.com
Now that I think of it, this would probably be a good argument for
differentiating between strong and weak. Looking back to my previous
comment, it probably would be best to have it behave the same
regardless of
what the incompatible type is. But in the case where a float might
sneak
its way into an int, the developer might decide that going with a weak
type
would make it more flexible (though if it was me, I'd just do a round or
leave it a mixed type lol).--Kris
On Wed, Feb 29, 2012 at 11:09 AM, Kris Craig kris.craig@gmail.com
wrote:@Richard I think you made a very good point. Should we treat a float
=>
int mismatch the same as we would a string => int mismatch, or should
the
former fail more gracefully? I can see good arguments for both.--Kris
On Wed, Feb 29, 2012 at 10:02 AM, Richard Lynch ceo@l-i-e.com
wrote:Some cases I would find interesting to be explained:
(using 'streak' for strong and/or weak, feel free to separate the
two)streak int $i = 123.456; //Common idiom for
floor()
streak int $i = "123.456"; //In contrast to previous
streak int $i = "1 "; //value="1 " is ridiculously common HTMLIt's all well and good to say that any loss of data is "bad" and to
raise some E_* for it, but there are some idioms so common that feel
"wrong" as I consider them...If everyone "for" the new type hinting/forcing can reach consensus on
these sorts of cases, it would help clarify any RFCs a bit, I thinkwrt
E_RECOVERABLE_ERRORvsE_WARNINGIf current type hinting raises E_RECOVERABLE_ERROR, I have no
objection to following that lead, with the explicit caveat that a
change to the existing type-hinting to E_WARNING, as unlikely as that
seems, would pull the new "streak" with it.I don't even object to using
E_ERRORfor the "strong" variant, if
that
passes review, really, since "strong" is, errr, strong. :-)Anybody who doesn't like the E_* can re-define them in a custom error
handler anyway, though allowing PHP to continue afterE_ERRORis like
playing russian roulette...--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
Personally, while I see the value in recycling what's already there, I
think that would just make things WAY more confusing than they need to be.
Some of these RFC's are years old and appear to have since been abandoned.
I think it would be better to have a procedure for removing "dead" RFC's
after a certain period of inactivity (like 6 months).
In any case, given the complexity involved, I think it would make much more
sense to create an RFC from scratch. Since the strong/weak question is
integral to this, having them in separate RFC's wouldn't work I don't
think. For example, what if the strong/weak one passed, but the one about
type hinting failed? I think that would just set a bad precedent for the
RFC process, since currently we don't have a system for having "RFC
dependencies."
Hence why I think the most sensible approach is to do this in one single
vote. The question is, how should that vote be structured?
I think what we need to do is amend the voting process before tackling
this, because there's just no good way to handle this right now without
arbitrarily creating a majority standard that doesn't currently exist.
So, here's what I'm thinking: An RFC can contain one "primary" question
and zero or more "secondary" questions. The primary question would be the
way it's setup now; all those rules would be unchanged. However, what if
there are multiple approaches to how this RFC can be implemented? It
stands to reason that, for example, a clear 2/3 majority can agree that
this should be implemented, but there is no clear majority with regard to
which method should be used. The more options there are, the more likely
it is that the vote will be perpetually split, essentially preventing that
feature from moving forward despite having supermajority support.
Therefore, a "secondary" question would be defined as a question that does
not materially affect anything outside the immediate scope of the primary
question and does not contain any voting options that would prevent the
primary question from being implemented. As such, since the secondary
question can have a theoretical infinite number of possible answers, the
standard for passage would be a simple plurality; i.e. whichever option has
the most votes would be the one used to implement the primary question, if
passed (if the primary question fails, then the secondary question is
meaningless). In the event of a tie, I would say extend the voting period
until someone breaks the tie.
What do you think? I believe this would not only be helpful to us now, but
would also improve the RFC voting process overall by making it much more
flexible. I can write an RFC for this if anyone thinks it has merit.
--Kris
On Wed, Feb 29, 2012 at 12:57 PM, Simon Schick
simonsimcity@googlemail.comwrote:
Hi, Kris
As we have some RFCs around that we should update them I think.
In my opinion we should split them up into 3 RFCs (and one grouping RFC):
Weak and strong type-checks (whatever that in detail means) should be
discussed in one single RFC. The option1 in the existing one is pretty
close to what I expect it to be - but why should f.e. "12abc" be a valid
integer? As said - we should update that.
https://wiki.php.net/rfc/typecheckingstrictandweakSplit the following RFC into two RFCs. Parameter type-hint and return
type-hint:
https://wiki.php.net/rfc/typehintUntil now we have two RFCs for return type-hint that should also be
combined. Add the information from the last mentioned here as well:
https://wiki.php.net/rfc/returntypehint2
https://wiki.php.net/rfc/returntypehintAnd finally update the grouping-RFC:
https://wiki.php.net/rfc/typecheckingThe RFCs for parameter- and return-type-hint should not contain the
definition of strict or weak type-hints.
After all three RFCs have been voted by a bunch of people we can write
down a RFC for a combination - f.e. how it should look like to have weak
function type-hinting or strong return type-hinting.So .. here's quite a lot of work to do to gather the people who wrote
these RFCs and let their ideas float into one specific definition with
several options how to implement them.Bye
Simon2012/2/29 Kris Craig kris.craig@gmail.com
And here's a thought: I could structure the RFC so that the voting will
have 3 choices: Yes with strong/weak differentiation, yes without
strong/weak, or no. However, the voting RFC doesn't cover how the tally
should be calculated in such a circumstance. For example, let's say we had
8 votes yes with differentiation, 2 votes yes without differentiation, and
5 votes no. If we tally the two "yes" columns, it's 10 - 5, which would be
the required 2/3 majority. However, how would we calculate the mandate on
differentiation? Among those who voted yes, there's a clear 8 - 2 (80%)
majority in favor of it. But if you count the no votes as being no to
differentiation and add them to the total, it suddenly becomes 8 - 7, which
falls short of the 2/3 majority. An argument could be made that these
people who voted no would not want differentiation, but another argument
could be made that; while they don't like the idea, if it does happen
they'd rather have it differentiated than not. In other words, determining
voter intent from that group would be difficult and thus only tallying
among the yes votes would make sense. Both arguments would have about
equal merit I thinkThe voting RFC does allow for different "options" in the vote, but it
does not elaborate on this. We could break the "no" group into two as
well, though that could make things a bit too confusing.Since there's presently no clear procedure on this (at least none that
I'm aware of), what are your thoughts on this? I do believe the two should
be in the same vote since they're pretty integral to one another, but I'm
not sure how best to do that while maintaining accurate results without
making it too complicated.--Kris
On Wed, Feb 29, 2012 at 12:18 PM, Kris Craig kris.craig@gmail.comwrote:
@Simon Agreed. That's pretty much what I'm thinking it should look like.
With booleans, I think you have a good point. If 1 or 0 is passed to a
bool, I'd say that should be fine without an error. If you were to pass a
2, though (you insolent bastard!), then it would throw the error.I think we're getting pretty close to having enough to write an RFC for
this. I'll go ahead and create one after a little more discussion goes
around.--Kris
On Wed, Feb 29, 2012 at 11:50 AM, Simon Schick <
simonsimcity@googlemail.com> wrote:Hi, Kris
I don't think we have to care about scripts that are written right now
if we're talking about throwing anE_RECOVERABLE_ERRORorE_WARNINGbecause
this feature is completely new. But I like the idea to have all type-hint
failures ending up the same way.I personally would keep the error-messages for classes and arrays as
they are right now and do the same error in case the given value is not
compatible to the expected type.
Not compatible means that data gets lost after converting the data into
the other data-type.Lets have an example:
function foo(integer $i) {
// do something
}foo(true); // Even if Boolean is a lower type than int, it can be
easily casted to an int. It's equivalent to 1.
foo("1"); // wont throw an error because the transformation into an
integer is loose-less
foo(2.5); // Throws anE_RECOVERABLE_ERRORbecause its a float, but an
integer is required here.
foo("horse"); // Throws anE_RECOVERABLE_ERRORbecause if you transform
"horse" into a float, it's 1 and that's not equal to the string anymore.I personally would treat float - int miss matches the same way as all
other stuff, because it cannot be converted loose-less.And if the Object-cast-stuff comes through, we have to think about this
in addition:
https://wiki.php.net/rfc/object_cast_magicclass MyInteger {
public function __castTo(string $type) {
if ($type === "integer")
return 5;
}
}function foo(integer $i) {
// do something
}foo(new MyInteger()); // Even if this is an object - it's cast-able to
an integer and therefore should be validBut this is just in case the RFC gets through ;) We don't have to think
that much about it now - just keep it in mind.Bye
Simon2012/2/29 Kris Craig kris.craig@gmail.com
Now that I think of it, this would probably be a good argument for
differentiating between strong and weak. Looking back to my previous
comment, it probably would be best to have it behave the same
regardless of
what the incompatible type is. But in the case where a float might
sneak
its way into an int, the developer might decide that going with a weak
type
would make it more flexible (though if it was me, I'd just do a round
or
leave it a mixed type lol).--Kris
On Wed, Feb 29, 2012 at 11:09 AM, Kris Craig kris.craig@gmail.com
wrote:@Richard I think you made a very good point. Should we treat a
float =>
int mismatch the same as we would a string => int mismatch, or
should the
former fail more gracefully? I can see good arguments for both.--Kris
On Wed, Feb 29, 2012 at 10:02 AM, Richard Lynch ceo@l-i-e.com
wrote:Some cases I would find interesting to be explained:
(using 'streak' for strong and/or weak, feel free to separate the
two)streak int $i = 123.456; //Common idiom for
floor()
streak int $i = "123.456"; //In contrast to previous
streak int $i = "1 "; //value="1 " is ridiculously common HTMLIt's all well and good to say that any loss of data is "bad" and to
raise some E_* for it, but there are some idioms so common that feel
"wrong" as I consider them...If everyone "for" the new type hinting/forcing can reach consensus
on
these sorts of cases, it would help clarify any RFCs a bit, I thinkwrt
E_RECOVERABLE_ERRORvsE_WARNINGIf current type hinting raises E_RECOVERABLE_ERROR, I have no
objection to following that lead, with the explicit caveat that a
change to the existing type-hinting to E_WARNING, as unlikely as
that
seems, would pull the new "streak" with it.I don't even object to using
E_ERRORfor the "strong" variant, if
that
passes review, really, since "strong" is, errr, strong. :-)Anybody who doesn't like the E_* can re-define them in a custom
error
handler anyway, though allowing PHP to continue afterE_ERRORis
like
playing russian roulette...--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
Guys, you probably are too deep into the discussion that you haven't
noticed an elephant Zeev has put into the room. When the RFC procces was
put in place there was a rule outlined - if core devs decide to reject,
it's rejected. And as Zeev said last time core dev team decided that there
will be no strict typing in PHP, period (btw, Zeev thanks for reminding
that). It's open source - if you want it badly, fork, patch and have your
party with black jack and girls.
Zeev i have just have one question - is it worth trying to get the type
hinting "the PHP way" (that converting thing that errors only on really bad
missmatches like asking for int and getting an array or object)? I
understand the argument that if rules of conversion are not changed, then
basically not much is changed. But from the code writing prespective it
becomes easier, because with converting type hint you do not need to make
explict conversions all over the code - it's done at calll time and that
simplifies things, sometimes a lot. Second - the reflection then does not
rely on phpdoc to get the types (and i remember there was an issue with
opcode caching and phpdoc being stripped and so not avaliable).
It good to have array and object hints, but i miss the
integer/string/boolean/double hints more times than i want to admit really
:-)
Kris Craig wrote:
With booleans, I think you have a good point. If 1 or 0 is passed to a
bool, I'd say that should be fine without an error. If you were to pass a
2, though (you insolent bastard!), then it would throw the error.
I have to complain about that. There is nothing wrong in my book with assuming
that a returned value is true while an empty return is false. Having to check
for a number greater than zero rather than just 'true' is complicating things
again. If it returned some values from the DB query it's 'not false' and we can
go on.
But my main concern/complaint here is that I am more than happy with my IDE
doing all of the type hinting that I need, so there is no need to load down the
runtime engine with this. Perhaps now is the time to make a formal request that
a lot of this 'compiler' like construction show have an overall 'off' switch so
we can run scripts faster? PHPEclipse picks up the phpdoc comment blocks and
gives a hint popup that has served me well for years.
I know that there are always those say 'you do not have to use it', but with
these extensions starting to be applied to the very libraries we rely on, then
we are forced to learn about things that we do not actually need in production,
and once again we are wasting time on 'keeping up' when all we want is a
reliable stable base we can rely on.
I'm being forced to accept Smarty3 because 'that is the supported version' when
converting several years worth of Smarty2 templates is totally impractical. And
libraries like Smarty3 tend to include the very constructs you are discussing
'because they are the modern way'. Perhaps it is about time us old fuddy duddys
started to support a frozen stable version of PHP and it's libraries that just
get essential security updates and let you 'modern guys' get on with your own
branch .....
--
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
-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]@Richard I think you made a very good point. Should we treat a float => int mismatch the same as we would a string => int mismatch, or should the former fail more gracefully? I can see good arguments for both.
--Kris
I'm beginning to think that the type hinting question is too closely related to the dirty secrets of type juggling to resolve them separately. You may have to either discard consistency, or else fix the problem of silent bizarre conversions at the same time ('foo'==0, '123abc'=123). Fixing the conversions is a BC break though.
John Crenshaw
Priacta, Inc.
I was thinking something more along the lines of simply throwing an error
if, say, (int) $a != $a.... *if *$a is defined as an integer.
--Kris
On Wed, Feb 29, 2012 at 5:16 PM, John Crenshaw johncrenshaw@priacta.comwrote:
-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]@Richard I think you made a very good point. Should we treat a float =>
int mismatch the same as we would a string => int mismatch, or should the
former fail more gracefully? I can see good arguments for both.--Kris
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them separately.
You may have to either discard consistency, or else fix the problem of
silent bizarre conversions at the same time ('foo'==0, '123abc'=123).
Fixing the conversions is a BC break though.John Crenshaw
Priacta, Inc.
I was thinking something more along the lines of simply throwing an error
if, say, (int) $a != $a.... *if *$a is defined as an integer.--Kris
On Wed, Feb 29, 2012 at 5:16 PM, John Crenshaw <johncrenshaw@priacta.com
wrote:
-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]@Richard I think you made a very good point. Should we treat a float
=>
int mismatch the same as we would a string => int mismatch, or should the
former fail more gracefully? I can see good arguments for both.--Kris
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them separately.
You may have to either discard consistency, or else fix the problem of
silent bizarre conversions at the same time ('foo'==0, '123abc'=123).
Fixing the conversions is a BC break though.John Crenshaw
Priacta, Inc.
John raises some real concerns about the relation of hinting and juggling.
I'm wondering about allowing developers to declare type intentions (I'll
post an idea in a separate thread.)
Adam
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.
[short version]
One man's "fixing" is another man's "feature" :-)
Old hands can now hit delete while I wax philosophical.
[long version]
PHP does the type juggling because HTTP data is all string. It's a
feature, because PHP's main purpose was to process HTTP input.
[Yes, I know you did not dispute this. It's just foreshadowing...]
Once one accepts the premise that automatic type-juggling is "good",
the idea that (int) "123 abc" turns into 123 may seem incredibly
"wrong" or "right" depending on how useful one has found it.
I have found it useful, and others have as well, to the point that we
don't consider it something to "fix" but a "feature"
Obviously, others disagree. And that's okay. We "get" that some
disagree, and even why some disagree. We've all coded in C, C++, C#,
Forth, Modula 2, Lisp, PL/1, and many more, collectively.
We choose PHP, at times, because it is the way it is, as "broken" as
it may seem to others. And they are legion. One only needs to review
blogs and mailing lists of fans of other strictly-typed languages to
see this.
But Breaking Compatibility with something so deeply ingrained in the
culture and language, which goes back consistently at least to PHP3,
and probably PHP/FI, is a non-starter.
There are probably literally millions of scripts that will break "out
there." That's simply unacceptable, and I trust you understand why
that is so.
You might consider those scripts poor programming practice. We all do.
But PHP is the language of the unwashed masses, and that was, and is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody useful
web application, breaking 10,000 Computer Science rules along the way.
It's duct tape and bailing wire. And we love it for that.
If the app is useful enough, it might even get cleaned up. Or just
more duct tape and bailing wire is applied, more likely. :-)
Even at a major release, PHP has, by and large, strived to remain
Backwards Compatible, unless a VERY compelling reason was presented.
A vocal minority, or even a majority, of developers does not qualify.
That's pretty much why the Core Devs' "veto" power exists.
Some of the proposals and ideas lately have adhered to that concept of
not breaking Backwards Compatibility. Others have not, and those are
just non-starters.
But PHP core has always had the mantra "Keep It Simple, Stupid"
If one wants a complex language, PHP is simply not going to be it, and
virtually all of these proposals do not fit the KISS principle, at a
fundamental level of "Any idiot can read halfway decent code and
puzzle out what it does in less than a day."
This is a Religious Issue, a personal preference, a philosophical
ideal, etc. Right or wrong, it is what it is, by choice, by the core
developers who have put years worth of effort into it.
Please don't read this as "go away" or a restatement of the arguments
that have been labeled as circular before. I am merely trying to
explain why PHP is the way it is, at a 10,000 foot level, and why so
many core devs are resistant to the changes being proposed.
I highly respect all the efforts and the alternative philosophical
differences, and even the guiding principles of Computer Science
driving them. PHP is just not the language for Computer Science types,
for the most part. It's for the masses.
Some CS types like it in certain situations, which is all to the good,
or it would be a total mess :-) We embrace its "flaws" and ugly hacks
because, like it or not, "it works" for what it's designed to do.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
I agree with your well-thought-out remarks overall. However (and you knew
a "however" was coming lol), by making these types optional, we would be
allowing full backwards-compatibility without alienating non-CS developers,
since they would be able to continue writing the same code they do now.
Likewise, and I know I keep going back to this, PHP 5's stronger
implementation of OO did not break backwards compatibility or scare away
procedural developers who are not versed on OO concepts. I would cite that
as precedent for this; in that, if done correctly and with great care, this
can be implemented without trampling on PHP's KISS principles IMHO.
--Kris
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.[short version]
One man's "fixing" is another man's "feature" :-)Old hands can now hit delete while I wax philosophical.
[long version]
PHP does the type juggling because HTTP data is all string. It's a
feature, because PHP's main purpose was to process HTTP input.
[Yes, I know you did not dispute this. It's just foreshadowing...]Once one accepts the premise that automatic type-juggling is "good",
the idea that (int) "123 abc" turns into 123 may seem incredibly
"wrong" or "right" depending on how useful one has found it.I have found it useful, and others have as well, to the point that we
don't consider it something to "fix" but a "feature"Obviously, others disagree. And that's okay. We "get" that some
disagree, and even why some disagree. We've all coded in C, C++, C#,
Forth, Modula 2, Lisp, PL/1, and many more, collectively.We choose PHP, at times, because it is the way it is, as "broken" as
it may seem to others. And they are legion. One only needs to review
blogs and mailing lists of fans of other strictly-typed languages to
see this.But Breaking Compatibility with something so deeply ingrained in the
culture and language, which goes back consistently at least to PHP3,
and probably PHP/FI, is a non-starter.There are probably literally millions of scripts that will break "out
there." That's simply unacceptable, and I trust you understand why
that is so.You might consider those scripts poor programming practice. We all do.
But PHP is the language of the unwashed masses, and that was, and is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody useful
web application, breaking 10,000 Computer Science rules along the way.It's duct tape and bailing wire. And we love it for that.
If the app is useful enough, it might even get cleaned up. Or just
more duct tape and bailing wire is applied, more likely. :-)Even at a major release, PHP has, by and large, strived to remain
Backwards Compatible, unless a VERY compelling reason was presented.A vocal minority, or even a majority, of developers does not qualify.
That's pretty much why the Core Devs' "veto" power exists.Some of the proposals and ideas lately have adhered to that concept of
not breaking Backwards Compatibility. Others have not, and those are
just non-starters.But PHP core has always had the mantra "Keep It Simple, Stupid"
If one wants a complex language, PHP is simply not going to be it, and
virtually all of these proposals do not fit the KISS principle, at a
fundamental level of "Any idiot can read halfway decent code and
puzzle out what it does in less than a day."This is a Religious Issue, a personal preference, a philosophical
ideal, etc. Right or wrong, it is what it is, by choice, by the core
developers who have put years worth of effort into it.Please don't read this as "go away" or a restatement of the arguments
that have been labeled as circular before. I am merely trying to
explain why PHP is the way it is, at a 10,000 foot level, and why so
many core devs are resistant to the changes being proposed.I highly respect all the efforts and the alternative philosophical
differences, and even the guiding principles of Computer Science
driving them. PHP is just not the language for Computer Science types,
for the most part. It's for the masses.Some CS types like it in certain situations, which is all to the good,
or it would be a total mess :-) We embrace its "flaws" and ugly hacks
because, like it or not, "it works" for what it's designed to do.--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
You might consider those scripts poor programming practice. We all do.
But PHP is the language of the unwashed masses, and that was, and is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody useful
web application, breaking 10,000 Computer Science rules along the way.
And in 20 minutes I can hack into that application 20 different ways. This isn't really PHP's fault...or is it? By deliberately catering to the lowest possible denominator is it possible that PHP itself contributes to the proliferation of wildly insecure web sites? I do understand the "unwashed masses" argument, and yet, the security geek in me sometimes questions how "good" this is.
(Before someone flames me, I'm not really saying that we should scrap any foundational principles or tell basic users to go hang themselves. This is mostly philosophical musing.)
John Crenshaw
Priacta, Inc.
Secure code is not about the instrument, it's about how you write it.
Insecure spagetti code can be written in any language.
You might consider those scripts poor programming practice. We all
do.
But PHP is the language of the unwashed masses, and that was, and
is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody useful
web application, breaking 10,000 Computer Science rules along the
way.And in 20 minutes I can hack into that application 20 different ways.
This isn't really PHP's fault...or is it? By deliberately catering to
the lowest possible denominator is it possible that PHP itself
contributes to the proliferation of wildly insecure web sites? I do
understand the "unwashed masses" argument, and yet, the security geek
in me sometimes questions how "good" this is.(Before someone flames me, I'm not really saying that we should scrap
any foundational principles or tell basic users to go hang themselves.
This is mostly philosophical musing.)
We make concerted efforts to educate scripters, by posting the same
thing in all our blogs.
Even if all they understand is "Don't do this!" it's good enough for
most of them.
Other times the decision was made to just deprecate a "feature" and
provide a migration path, if suitable, but spread out over major
releases:
PHP x.0: Feature is bad, but there
PHP x+1.0 Feature is E_DEPRECATED (or documented as such before E_DEP)
[This is the bit where a LOT of scripted edumacation has to happen.)
PHP x+2.0 Feature is just gone.
People who completely ignore docs or don't upgrade remain vulnerable,
but there's not much you can do without making life miserable for a
bazillion developers.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
From: Richard Lynch [mailto:ceo@l-i-e.com]
You might consider those scripts poor programming practice. We all
do.
But PHP is the language of the unwashed masses, and that was, and is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody useful
web application, breaking 10,000 Computer Science rules along the
way.And in 20 minutes I can hack into that application 20 different ways.
This isn't really PHP's fault...or is it? By deliberately catering to
the lowest possible denominator is it possible that PHP itself
contributes to the proliferation of wildly insecure web sites? I do
understand the "unwashed masses" argument, and yet, the security geek
in me sometimes questions how "good" this is.(Before someone flames me, I'm not really saying that we should scrap
any foundational principles or tell basic users to go hang themselves.
This is mostly philosophical musing.)We make concerted efforts to educate scripters, by posting the same thing in all our blogs.
Even if all they understand is "Don't do this!" it's good enough for most of them.
Other times the decision was made to just deprecate a "feature" and provide a migration path,
if suitable, but spread out over major
releases:
PHP x.0: Feature is bad, but there
PHP x+1.0 Feature isE_DEPRECATED(or documented as such before E_DEP) [This is the bit
where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature is just gone.People who completely ignore docs or don't upgrade remain vulnerable, but there's not much
you can do without making life miserable for a bazillion developers.
No, you've misunderstood. The average new not-really-a-developer has no concept of security. Every SQL query they write is vulnerable to injection. Every echo exposes their site to XSS vulnerabilities. Every form is vulnerable to CSRF. If they did anything with files in their script I may be able to read arbitrary files to their server and/or upload and execute arbitrary scripts. If they used eval() or system() I can probably execute arbitrary shell code and take control of the entire site. If their server is badly configured I could capture the entire machine.
This isn't a question of keeping software updated and not using deprecated functions, this is a question of discipline that is completely missing among the "unwashed masses" as you call them. The intuitive way to handle many of the most common PHP tasks is also the completely insecure way. Philosophically, I wonder if we do a great disservice by encouraging these people to tinker with code at all. We do so knowing (or at least we should know) that anything they create will inevitably be hacked. We fuel the widespread security problems that currently plague the web.
John Crenshaw
Priacta, Inc.
I agree with what John said. Limiting the scope to scalars, while having
some advantages, probably wouldn't pass the "usefulness" test for most
people.
--Kris
On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw johncrenshaw@priacta.comwrote:
From: Richard Lynch [mailto:ceo@l-i-e.com]
You might consider those scripts poor programming practice. We all
do.
But PHP is the language of the unwashed masses, and that was, and is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody useful
web application, breaking 10,000 Computer Science rules along the
way.And in 20 minutes I can hack into that application 20 different ways.
This isn't really PHP's fault...or is it? By deliberately catering to
the lowest possible denominator is it possible that PHP itself
contributes to the proliferation of wildly insecure web sites? I do
understand the "unwashed masses" argument, and yet, the security geek
in me sometimes questions how "good" this is.(Before someone flames me, I'm not really saying that we should scrap
any foundational principles or tell basic users to go hang themselves.
This is mostly philosophical musing.)We make concerted efforts to educate scripters, by posting the same
thing in all our blogs.Even if all they understand is "Don't do this!" it's good enough for
most of them.Other times the decision was made to just deprecate a "feature" and
provide a migration path,
if suitable, but spread out over major
releases:
PHP x.0: Feature is bad, but there
PHP x+1.0 Feature isE_DEPRECATED(or documented as such before E_DEP)
[This is the bit
where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature is
just gone.People who completely ignore docs or don't upgrade remain vulnerable,
but there's not much
you can do without making life miserable for a bazillion developers.No, you've misunderstood. The average new not-really-a-developer has no
concept of security. Every SQL query they write is vulnerable to injection.
Every echo exposes their site to XSS vulnerabilities. Every form is
vulnerable to CSRF. If they did anything with files in their script I may
be able to read arbitrary files to their server and/or upload and execute
arbitrary scripts. If they used eval() orsystem()I can probably execute
arbitrary shell code and take control of the entire site. If their server
is badly configured I could capture the entire machine.This isn't a question of keeping software updated and not using deprecated
functions, this is a question of discipline that is completely missing
among the "unwashed masses" as you call them. The intuitive way to handle
many of the most common PHP tasks is also the completely insecure way.
Philosophically, I wonder if we do a great disservice by encouraging these
people to tinker with code at all. We do so knowing (or at least we should
know) that anything they create will inevitably be hacked. We fuel the
widespread security problems that currently plague the web.John Crenshaw
Priacta, Inc.
Hi, Kris
I have to confirm that that's not really what I wanted.
But many people were now talking about type-hint to scalar, but that was
maybe in another thread in this list :)
To get more to the point what were discussing about want:
Why not always (at least try) to transform the data?
In PHP 5.4 they've introduced quite a lot of new stuff around exactly that:
- Changed silent conversion of array to string to produce a notice.
- Changed silent casting of null/''/false into an Object when adding a
property into a warning.
I would suppose to add a type-hint for the following types:
- Boolean
- integer
- float
- string
Here's the last state what I thought about these type-hints ...
Both of the given examples here should give the same result:
foo(boolean $b, integer $i, float $f, string $s) {
// your code
}
foo2($b, $i, $f, $s) {
$b = (boolean)$b;
$i = (integer)$i;
$f = (float)$f;
$s = (string)$s;
// your code
}
If you view it from that site - you can't get an array to do what you can
do with an object. Therefore I think it's quite OK to break the script
there, but here, as you can transform the values, I'd (at least try to)
transform the given data into the expected format.
The only thing I'm quite unsure about - should we trigger a E_WARNING or
E_NOTICE if we have data-loose in this transformation? Just let it pass as
it's transformable, but trigger some error ...
If you want to get a warning or notice in the function foo2 then open a
new thread, as I think that should not be discussed here. It affects much
more than just the function-call.
p.s. What about adding another type-hint for resources?
That's something we could check by is_resource() and it would make sense
(at least to me).
Bye
Simon
2012/3/2 Kris Craig kris.craig@gmail.com
I agree with what John said. Limiting the scope to scalars, while having
some advantages, probably wouldn't pass the "usefulness" test for most
people.--Kris
On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw <johncrenshaw@priacta.com
wrote:
From: Richard Lynch [mailto:ceo@l-i-e.com]
You might consider those scripts poor programming practice. We all
do.
But PHP is the language of the unwashed masses, and that was, and
is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody useful
web application, breaking 10,000 Computer Science rules along the
way.And in 20 minutes I can hack into that application 20 different ways.
This isn't really PHP's fault...or is it? By deliberately catering to
the lowest possible denominator is it possible that PHP itself
contributes to the proliferation of wildly insecure web sites? I do
understand the "unwashed masses" argument, and yet, the security geek
in me sometimes questions how "good" this is.(Before someone flames me, I'm not really saying that we should scrap
any foundational principles or tell basic users to go hang
themselves.
This is mostly philosophical musing.)We make concerted efforts to educate scripters, by posting the same
thing in all our blogs.Even if all they understand is "Don't do this!" it's good enough for
most of them.Other times the decision was made to just deprecate a "feature" and
provide a migration path,
if suitable, but spread out over major
releases:
PHP x.0: Feature is bad, but there
PHP x+1.0 Feature isE_DEPRECATED(or documented as such before E_DEP)
[This is the bit
where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature
is
just gone.People who completely ignore docs or don't upgrade remain vulnerable,
but there's not much
you can do without making life miserable for a bazillion developers.No, you've misunderstood. The average new not-really-a-developer has no
concept of security. Every SQL query they write is vulnerable to
injection.
Every echo exposes their site to XSS vulnerabilities. Every form is
vulnerable to CSRF. If they did anything with files in their script I may
be able to read arbitrary files to their server and/or upload and execute
arbitrary scripts. If they used eval() orsystem()I can probably execute
arbitrary shell code and take control of the entire site. If their server
is badly configured I could capture the entire machine.This isn't a question of keeping software updated and not using
deprecated
functions, this is a question of discipline that is completely missing
among the "unwashed masses" as you call them. The intuitive way to handle
many of the most common PHP tasks is also the completely insecure way.
Philosophically, I wonder if we do a great disservice by encouraging
these
people to tinker with code at all. We do so knowing (or at least we
should
know) that anything they create will inevitably be hacked. We fuel the
widespread security problems that currently plague the web.John Crenshaw
Priacta, Inc.
Hi, All
Let me update my last functions as I got an inspiration from Anthony and
his proof-of-concept:
foo( (boolean) $b, (integer) $i, (float) $f, (string) $s) {
// your code
}
foo2($b, $i, $f, $s) {
$b = (boolean)$b;
$i = (integer)$i;
$f = (float)$f;
$s = (string)$s;
// your code
}
Now here a rule I thought could be acceptable to differ between the
type-hint for classes and arrays and this notation:
If the type is wrapped in parentheses, the system will try to convert the
given value. Otherwise it will handle it strict.
Strict is currently only available for classes and arrays, and I don't want
to get more things in this list (excepted by resources, what is the last
what would make sense here).
Dynamic (the one with the parentheses) could then well be something like
boolean, integer, float, string and array. Array is also in this list as I
would like to have an option to give an object in here that implements all
interfaces that makes an object accessible as an array - for example
ArrayIterator.
Bye
Simon
2012/3/2 Simon Schick simonsimcity@googlemail.com
Hi, Kris
I have to confirm that that's not really what I wanted.
But many people were now talking about type-hint to scalar, but that was
maybe in another thread in this list :)To get more to the point what were discussing about want:
Why not always (at least try) to transform the data?In PHP 5.4 they've introduced quite a lot of new stuff around exactly that:
- Changed silent conversion of array to string to produce a notice.
- Changed silent casting of null/''/false into an Object when adding a
property into a warning.I would suppose to add a type-hint for the following types:
- Boolean
- integer
- float
- string
Here's the last state what I thought about these type-hints ...
Both of the given examples here should give the same result:foo(boolean $b, integer $i, float $f, string $s) {
// your code
}
foo2($b, $i, $f, $s) {
$b = (boolean)$b;
$i = (integer)$i;
$f = (float)$f;
$s = (string)$s;// your code
}If you view it from that site - you can't get an array to do what you can
do with an object. Therefore I think it's quite OK to break the script
there, but here, as you can transform the values, I'd (at least try to)
transform the given data into the expected format.
The only thing I'm quite unsure about - should we trigger aE_WARNINGor
E_NOTICEif we have data-loose in this transformation? Just let it pass as
it's transformable, but trigger some error ...
If you want to get a warning or notice in the function foo2 then open a
new thread, as I think that should not be discussed here. It affects much
more than just the function-call.p.s. What about adding another type-hint for resources?
That's something we could check by is_resource() and it would make
sense (at least to me).Bye
Simon2012/3/2 Kris Craig kris.craig@gmail.com
I agree with what John said. Limiting the scope to scalars, while having
some advantages, probably wouldn't pass the "usefulness" test for most
people.--Kris
On Thu, Mar 1, 2012 at 4:18 PM, John Crenshaw <johncrenshaw@priacta.com
wrote:
From: Richard Lynch [mailto:ceo@l-i-e.com]
You might consider those scripts poor programming practice. We all
do.
But PHP is the language of the unwashed masses, and that was, and
is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody
useful
web application, breaking 10,000 Computer Science rules along the
way.And in 20 minutes I can hack into that application 20 different
ways.
This isn't really PHP's fault...or is it? By deliberately catering
to
the lowest possible denominator is it possible that PHP itself
contributes to the proliferation of wildly insecure web sites? I do
understand the "unwashed masses" argument, and yet, the security
geek
in me sometimes questions how "good" this is.(Before someone flames me, I'm not really saying that we should
scrap
any foundational principles or tell basic users to go hang
themselves.
This is mostly philosophical musing.)We make concerted efforts to educate scripters, by posting the same
thing in all our blogs.Even if all they understand is "Don't do this!" it's good enough for
most of them.Other times the decision was made to just deprecate a "feature" and
provide a migration path,
if suitable, but spread out over major
releases:
PHP x.0: Feature is bad, but there
PHP x+1.0 Feature isE_DEPRECATED(or documented as such before E_DEP)
[This is the bit
where a LOT of scripted edumacation has to happen.) PHP x+2.0 Feature
is
just gone.People who completely ignore docs or don't upgrade remain vulnerable,
but there's not much
you can do without making life miserable for a bazillion developers.No, you've misunderstood. The average new not-really-a-developer has no
concept of security. Every SQL query they write is vulnerable to
injection.
Every echo exposes their site to XSS vulnerabilities. Every form is
vulnerable to CSRF. If they did anything with files in their script I
may
be able to read arbitrary files to their server and/or upload and
execute
arbitrary scripts. If they used eval() orsystem()I can probably
execute
arbitrary shell code and take control of the entire site. If their
server
is badly configured I could capture the entire machine.This isn't a question of keeping software updated and not using
deprecated
functions, this is a question of discipline that is completely missing
among the "unwashed masses" as you call them. The intuitive way to
handle
many of the most common PHP tasks is also the completely insecure way.
Philosophically, I wonder if we do a great disservice by encouraging
these
people to tinker with code at all. We do so knowing (or at least we
should
know) that anything they create will inevitably be hacked. We fuel the
widespread security problems that currently plague the web.John Crenshaw
Priacta, Inc.
No, you've misunderstood. The average new not-really-a-developer has no concept of security. Every SQL query they write is vulnerable to injection. Every echo exposes their site to XSS vulnerabilities. Every form is vulnerable to CSRF. If they did anything with files in their script I may be able to read arbitrary files to their server and/or upload and execute arbitrary scripts. If they used eval() or
system()I can probably execute arbitrary shell code and take control of the entire site. If their server is badly configured I could capture the entire machine.
PHP is as vulnerable as you make it,
This isn't a question of keeping software updated and not using deprecated functions, this is a question of discipline that is completely missing among the "unwashed masses" as you call them. The intuitive way to handle many of the most common PHP tasks is also the completely insecure way. Philosophically, I wonder if we do a great disservice by encouraging these people to tinker with code at all. We do so knowing (or at least we should know) that anything they create will inevitably be hacked. We fuel the widespread security problems that currently plague the web.
John Crenshaw
Priacta, Inc.
From: Richard Lynch [mailto:ceo@l-i-e.com]
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.[short version]
One man's "fixing" is another man's "feature" :-)Old hands can now hit delete while I wax philosophical.
The operative word was "silent". The actual behavior is fine, but the silence is unexpected. For example, PHP happily accepts substr('foo', 'bar') with no complaint at all. From a purely philosophical perspective I think almost everyone would expect at least a strict notice.
On a practical level, we have a major barrier and we'll have to decide how to handle it. As I see it we could do one of the following:
- Discard consistency (!!)
- Try to convince people to make these bizarre conversions not silent (BC break)
- Try to find a creative solution to be consistent without changing anything about the conversion behavior. (I'm not seeing a way to do this one, unless we redefine "consistent".)
John Crenshaw
Priacta, Inc.
Hi, John
Just to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a E_NOTICE
or E_WARNING if we f.e. try to give a string to a method that just allows
integer for this argument?
No break at all, just a E_NOTICE or E_WARNING as the script can succeed
anyways.
Bye
Simon
2012/3/1 John Crenshaw johncrenshaw@priacta.com
From: Richard Lynch [mailto:ceo@l-i-e.com]
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.[short version]
One man's "fixing" is another man's "feature" :-)Old hands can now hit delete while I wax philosophical.
The operative word was "silent". The actual behavior is fine, but the
silence is unexpected. For example, PHP happily accepts substr('foo',
'bar') with no complaint at all. From a purely philosophical perspective I
think almost everyone would expect at least a strict notice.On a practical level, we have a major barrier and we'll have to decide how
to handle it. As I see it we could do one of the following:
- Discard consistency (!!)
- Try to convince people to make these bizarre conversions not silent (BC
break)- Try to find a creative solution to be consistent without changing
anything about the conversion behavior. (I'm not seeing a way to do this
one, unless we redefine "consistent".)John Crenshaw
Priacta, Inc.
From: Simon Schick [mailto:simonsimcity@googlemail.com]
Hi, John
Just to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a
E_NOTICEorE_WARNINGif we f.e. try to give a string to a method that just allows integer for this argument?
No break at all, just aE_NOTICEorE_WARNINGas the script can succeed anyways.Bye
Simon
That's what I was calling "inconsistent", specifically because (int)'foo' == 0 with no warning whatsoever, but int $a = 'foo' would be 0 with an error of some sort. Behavior with respect to when an error is raised is inconsistent. In both cases there is a very lossy conversion, why is there an error in one case and not the other? Inconsistent.
On the other hand if you add an error in the legacy case now that's a BC break. One might argue that it should always have given a notice, but it didn't, so it's a change, and a BC break. Pick your poison.
John Crenshaw
Priacta, Inc.
That's what I was calling "inconsistent", specifically because (int)'foo'
== 0 with no warning whatsoever, but int $a = 'foo' would be 0 with an
error of some sort. Behavior with respect to when an error is raised is
inconsistent. In both cases there is a very lossy conversion, why is there
an error in one case and not the other? Inconsistent.
+1
However, I would love to have int $a = 'foo' cast to 0 without any error.
New functionality without breaking BC.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/1 John Crenshaw johncrenshaw@priacta.com
From: Simon Schick [mailto:simonsimcity@googlemail.com]
Hi, John
Just to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a
E_NOTICEorE_WARNINGif we f.e. try to give a string to a method that just
allows integer for this argument?
No break at all, just aE_NOTICEorE_WARNINGas the script can succeed
anyways.Bye
SimonThat's what I was calling "inconsistent", specifically because (int)'foo'
== 0 with no warning whatsoever, but int $a = 'foo' would be 0 with an
error of some sort. Behavior with respect to when an error is raised is
inconsistent. In both cases there is a very lossy conversion, why is there
an error in one case and not the other? Inconsistent.On the other hand if you add an error in the legacy case now that's a BC
break. One might argue that it should always have given a notice, but it
didn't, so it's a change, and a BC break. Pick your poison.John Crenshaw
Priacta, Inc.
On Thu, Mar 1, 2012 at 9:52 AM, Simon Schick simonsimcity@googlemail.comwrote:
Hi, John
Just to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a
E_NOTICE
orE_WARNINGif we f.e. try to give a string to a method that just allows
integer for this argument?
No break at all, just aE_NOTICEorE_WARNINGas the script can succeed
anyways.Perhaps I missed something, but since 5.3, the new parameter parsing API
throws a Warning when types are not strictly honored.
This has been a major feature in favor of "cleaner" programming.
Try substr('foo', 'bar'), in PHP >= 5.3 and you get a warning and the
function returns null.
Julien.P
Bye
Simon2012/3/1 John Crenshaw johncrenshaw@priacta.com
From: Richard Lynch [mailto:ceo@l-i-e.com]
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.[short version]
One man's "fixing" is another man's "feature" :-)Old hands can now hit delete while I wax philosophical.
The operative word was "silent". The actual behavior is fine, but the
silence is unexpected. For example, PHP happily accepts substr('foo',
'bar') with no complaint at all. From a purely philosophical perspective
I
think almost everyone would expect at least a strict notice.On a practical level, we have a major barrier and we'll have to decide
how
to handle it. As I see it we could do one of the following:
- Discard consistency (!!)
- Try to convince people to make these bizarre conversions not silent
(BC
break)- Try to find a creative solution to be consistent without changing
anything about the conversion behavior. (I'm not seeing a way to do this
one, unless we redefine "consistent".)John Crenshaw
Priacta, Inc.
From: Richard Lynch [mailto:ceo@l-i-e.com]
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.[short version]
One man's "fixing" is another man's "feature" :-)Old hands can now hit delete while I wax philosophical.
The operative word was "silent". The actual behavior is fine, but the
silence is unexpected. For example, PHP happily accepts substr('foo',
'bar') with no complaint at all. From a purely philosophical perspective I
think almost everyone would expect at least a strict notice.On a practical level, we have a major barrier and we'll have to decide how
to handle it. As I see it we could do one of the following:
- Discard consistency (!!)
- Try to convince people to make these bizarre conversions not silent (BC
break)- Try to find a creative solution to be consistent without changing
anything about the conversion behavior. (I'm not seeing a way to do this
one, unless we redefine "consistent".)John Crenshaw
Priacta, Inc.--
Hi, John
Just to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a
E_NOTICE
orE_WARNINGif we f.e. try to give a string to a method that just allows
integer for this argument?
No break at all, just aE_NOTICEorE_WARNINGas the script can succeed
anyways.
Perhaps I missed something, but since 5.3, the new parameter parsing API
throws a Warning when types are not strictly honored.
This has been a major feature in favor of "cleaner" programming.Try substr('foo', 'bar'), in PHP >= 5.3 and you get a warning and the
function returns null.Julien.P
Bye
Simon
Ah, didn't notice the new behavior. That simplifies things substantially.
I also had another realization today, which is that there's already strong precedent for treating parameter hints more aggressively than a type cast. For example, you can cast between arrays and objects, with no errors, but the type hints will still generate errors. I think this settles the consistency issue for me.
John Crenshaw
Priacta, Inc.
Hi, John
Therefore I think it would be easy to explain how a type-hint for scalar
could work.
You can explain it as saying that the following two functions should be end
up in exactly the same result, whatever you're pasting into:
function foo_one(scalar $bar) {}
function foo_two($bar) {
if (!is_scalar($bar))
trigger_error("Catchable fatal error: Argument ? passed to ? must be a
scalar, ? given,", E_RECOVERABLE_ERROR);
}
The error-message is just an example - but that would keep the three
type-hint possibilities in one and the same functionality - like just
allowing exactly this type.
You cannot even pass a class that extends* ArrayIterator *into a property
that requires an array. So I think we should also here (at least for
scalar) do a really strict thing.
Bye
Simon
2012/3/1 John Crenshaw johncrenshaw@priacta.com
From: Richard Lynch [mailto:ceo@l-i-e.com]
I'm beginning to think that the type hinting question is too
closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time
('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.[short version]
One man's "fixing" is another man's "feature" :-)Old hands can now hit delete while I wax philosophical.
The operative word was "silent". The actual behavior is fine, but the
silence is unexpected. For example, PHP happily accepts substr('foo',
'bar') with no complaint at all. From a purely philosophical
perspective I
think almost everyone would expect at least a strict notice.On a practical level, we have a major barrier and we'll have to decide
how
to handle it. As I see it we could do one of the following:
- Discard consistency (!!)
- Try to convince people to make these bizarre conversions not silent
(BC
break)- Try to find a creative solution to be consistent without changing
anything about the conversion behavior. (I'm not seeing a way to do
this
one, unless we redefine "consistent".)John Crenshaw
Priacta, Inc.--
On Thu, Mar 1, 2012 at 9:52 AM, Simon Schick <
simonsimcity@googlemail.com> wrote:
Hi, JohnJust to add an idea to yours ..
Do you think it's a compatibility-break if we'd decide to send a
E_NOTICE
orE_WARNINGif we f.e. try to give a string to a method that just allows
integer for this argument?
No break at all, just aE_NOTICEorE_WARNINGas the script can succeed
anyways.
Perhaps I missed something, but since 5.3, the new parameter parsing API
throws a Warning when types are not strictly honored.
This has been a major feature in favor of "cleaner" programming.Try substr('foo', 'bar'), in PHP >= 5.3 and you get a warning and the
function returns null.Julien.P
Bye
SimonAh, didn't notice the new behavior. That simplifies things substantially.
I also had another realization today, which is that there's already strong
precedent for treating parameter hints more aggressively than a type cast.
For example, you can cast between arrays and objects, with no errors, but
the type hints will still generate errors. I think this settles the
consistency issue for me.John Crenshaw
Priacta, Inc.
From: Simon Schick [mailto:simonsimcity@googlemail.com]
Hi, John
Therefore I think it would be easy to explain how a type-hint for scalar could work.
You can explain it as saying that the following two functions should be end up in exactly the same result, whatever you're pasting into:
function foo_one(scalar $bar) {}
function foo_two($bar) {
if (!is_scalar($bar))
trigger_error("Catchable fatal error: Argument ? passed to ? must be a scalar, ? given,", E_RECOVERABLE_ERROR);
}
Type hints that only ensure that something is a scalar are a non-starter for me. I'm not going to waste my time on something like that. You're not going to get any better core support with this, and you'll alienate support from a majority of userland as well. The average function doesn't need "just a scalar, but any scalar will do". Most functions need something specific, like a string, or a number. sqrt('foo') doesn't make any sense, it needs a number, not just a scalar.
John Crenshaw
Priacta, Inc.
If any of you are interested in such change in PHP, please get
together and write a complete RFC. As I do not see any kind of
progress but, as you stated, some philosophical discussions. That's
all good but after 2 weeks, it is time to move forward (or stop).
Cheers,
I'm beginning to think that the type hinting question is too closely
related to the dirty secrets of type juggling to resolve them
separately. You may have to either discard consistency, or else fix
the problem of silent bizarre conversions at the same time ('foo'==0,
'123abc'=123). Fixing the conversions is a BC break though.[short version]
One man's "fixing" is another man's "feature" :-)Old hands can now hit delete while I wax philosophical.
[long version]
PHP does the type juggling because HTTP data is all string. It's a
feature, because PHP's main purpose was to process HTTP input.
[Yes, I know you did not dispute this. It's just foreshadowing...]Once one accepts the premise that automatic type-juggling is "good",
the idea that (int) "123 abc" turns into 123 may seem incredibly
"wrong" or "right" depending on how useful one has found it.I have found it useful, and others have as well, to the point that we
don't consider it something to "fix" but a "feature"Obviously, others disagree. And that's okay. We "get" that some
disagree, and even why some disagree. We've all coded in C, C++, C#,
Forth, Modula 2, Lisp, PL/1, and many more, collectively.We choose PHP, at times, because it is the way it is, as "broken" as
it may seem to others. And they are legion. One only needs to review
blogs and mailing lists of fans of other strictly-typed languages to
see this.But Breaking Compatibility with something so deeply ingrained in the
culture and language, which goes back consistently at least to PHP3,
and probably PHP/FI, is a non-starter.There are probably literally millions of scripts that will break "out
there." That's simply unacceptable, and I trust you understand why
that is so.You might consider those scripts poor programming practice. We all do.
But PHP is the language of the unwashed masses, and that was, and is,
part of why it is hugely popular. Somebody who barely understands
programming can pound away at the keyboard and write a bloody useful
web application, breaking 10,000 Computer Science rules along the way.It's duct tape and bailing wire. And we love it for that.
If the app is useful enough, it might even get cleaned up. Or just
more duct tape and bailing wire is applied, more likely. :-)Even at a major release, PHP has, by and large, strived to remain
Backwards Compatible, unless a VERY compelling reason was presented.A vocal minority, or even a majority, of developers does not qualify.
That's pretty much why the Core Devs' "veto" power exists.Some of the proposals and ideas lately have adhered to that concept of
not breaking Backwards Compatibility. Others have not, and those are
just non-starters.But PHP core has always had the mantra "Keep It Simple, Stupid"
If one wants a complex language, PHP is simply not going to be it, and
virtually all of these proposals do not fit the KISS principle, at a
fundamental level of "Any idiot can read halfway decent code and
puzzle out what it does in less than a day."This is a Religious Issue, a personal preference, a philosophical
ideal, etc. Right or wrong, it is what it is, by choice, by the core
developers who have put years worth of effort into it.Please don't read this as "go away" or a restatement of the arguments
that have been labeled as circular before. I am merely trying to
explain why PHP is the way it is, at a 10,000 foot level, and why so
many core devs are resistant to the changes being proposed.I highly respect all the efforts and the alternative philosophical
differences, and even the guiding principles of Computer Science
driving them. PHP is just not the language for Computer Science types,
for the most part. It's for the masses.Some CS types like it in certain situations, which is all to the good,
or it would be a total mess :-) We embrace its "flaws" and ugly hacks
because, like it or not, "it works" for what it's designed to do.--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Agreed. If conversion can occur without data loss (that is, if the
value being assigned is == the value that actually IS assigned) then
no error should occur.So
int $a = "1"; // no error. 1 == "1" so who cares?
int $a = 'House'; // error 0 != 'House', so this is a problem.
Actually, 0 == 'House' ;-)
Again, errors should only raise if the final value != source value.
strong int $a = "1"; // Converts to 1. May or may not throw an error (I'm
still on the fence).It this is an error, it is no longer PHP.
--
--
--
Tjerk
int $a = "1"; // no error. 1 == "1" so who cares?
int $a = 'House'; // error 0 != 'House', so this is a problem.
For the sake of consistency, please take into account this example, which
works in the current implementation of PHP:
$b = 1 + "1"; // no error, $b == 2
$b = 1 + "House"; // no error, $b == 1
So, I believe that, raising an error or not, is not a question of the new
RFC.
Should there be an error, then it has to be in every unsuccessful type
juggling, regardless of the final assignment to a type-locked variable.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/2/29 Michael Morris dmgx.michael@gmail.com
Agreed. If conversion can occur without data loss (that is, if the
value being assigned is == the value that actually IS assigned) then
no error should occur.So
int $a = "1"; // no error. 1 == "1" so who cares?
int $a = 'House'; // error 0 != 'House', so this is a problem.Again, errors should only raise if the final value != source value.
On Tue, Feb 28, 2012 at 6:03 PM, Rick WIdmer vchkpw@developersdesk.com
wrote:strong int $a = "1"; // Converts to 1. May or may not throw an error
(I'm
still on the fence).It this is an error, it is no longer PHP.
-----Original Message-----
From: Rick WIdmer [mailto:vchkpw@developersdesk.com]strong int $a = "1"; // Converts to 1. May or may not throw an error
(I'm still on the fence).[If] this is an error, it is no longer PHP.
Rick,
I know what you are getting at, and I even agree that this won't work, but please let's avoid extreme aggressive statements. This shuts down the discussion and just makes people angry at you. "This is no longer PHP" is an aggressive complaint that doesn't help anyone understand why this construct is a problem. Instead, please articulate the core problem with the proposal. In this case a better response would be something like: "This re-opens the viral poisoning problem with strict typing that's already been discussed. We can't do this unless you can solve that problem.".
Thanks,
John Crenshaw
Priacta, Inc.
Guys,
I've followed this thread silently so far, and I'm wondering what changed over the last ~1.5years that warrants a new discussion into that matter.
I think the previous discussion ended with a pretty clear directive that strict typing has no place in PHP. Rasmus said about the proposal back then "They aren't hints. It is strict typing and in its current form I would ask you guys not to call the 5.4 release PHP." - which put in one sentence what several others (myself included) put in many more words. So the 'strong'/'firm'/'strict'/whatnot version of what is being discussed here, should probably not be discussed at all. We've been through it, and rejected it.
Back when we rejected strict typing, we also 'killed' the other RFC[*] that was born out of that old discussion - the 'weak' auto-conversion RFC. If I recall correctly, it was for two reasons - one was that the proponents of the strict typing said they'll firmly object weak typing, and the other is that this RFC still had some issues that didn't seem obvious to hammer out (main one I recall is that sticking to PHP's standard type juggling rules meant that feature wasn't very useful, and we didn't feel very comfortable introducing brand new type juggling rules just for that feature). If you want to revive that discussion, I suggest you take a look at that RFC - confine yourselves to only work on stuff that stands a chance to get accepted (no strict typing) - and try to come up with good answers to the open questions. No point in redoing the whole discussion from scratch.
Zeev
[*]https://wiki.php.net/rfc/typecheckingstrictandweak
-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Tuesday, February 28, 2012 11:58 PM
To: John Crenshaw
Cc: Richard Lynch; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hintingErr sorry yes John is correct. I wasn't paying close enough attention.
Here's my vision of how that progression would look:
$a = "1"; // Current kosher unchanged.
weak int $a = "1"; // Converts to 1. No error thrown.
strong int $a = "1"; // Converts to 1. May or may not throw an error (I'm still on
the fence).$a = "blah"; // Current kosher unchanged.
weak int $a = "blah"; // Throws E_x error level.
strong int $a = "blah"; // Throws E_y error level.Where E_y > E_x.
--Kris
On Tue, Feb 28, 2012 at 1:52 PM, John Crenshaw
johncrenshaw@priacta.comwrote:No, In the example given there's an error on int $a = "1". There
should be no error because this juggles fine.John Crenshaw
Priacta, inc.-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Tuesday, February 28, 2012 4:47 PM
To: Richard Lynch
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting@Richard That's fairly close to what I'm thinking, yes. But there
seems to be a diverse range of ideas bouncing around right now, so at
present it's all in flux.--Kris
I think this is the main reason for differentiating between "strong"
(or
whatever word is appropriate) and "weak." The developer may very
well want their script to blow-up in such a case.I believe I actually "get it" now...
You want 3 layers:
$a = "1"; //current kosher unchanged weak int $a = "1"; // some E_x
error level strong int $a = "1"; // some E_y error level where E_y >
E_xIs that a correct summation?
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id
=F
S9NLTNEEKWBE--
To unsubscribe,
visit: http://www.php.net/unsub.php
....Aaaaaand here we go again. Every few days it seems, somebody jumps
into this thread and reminds us that strict typing is a bad idea, despite
the fact that we've already all agreed on that point about a gazillion
times.
As for past RFC's, I would recommend you review the voting procedure. If
an RFC is rejected, the policy does allow it to be re-introduced after 6
months. While we're not actually reviving a previously rejected RFC since
we're discussing a different approach, even if you were to apply that to
the broader conceptual level, this discussion is still perfectly kosher
since, as you said, that rejection happened 1.5 years ago (3 times the
required period).
Sorry if my tone is a bit frustrated, but I think we're all a bit annoyed
at this repetitive pattern by now. We start finding common ground and
making progress, then somebody new makes a post about the evils of strict
typing and questioning why we're talking about this, obviously completely
ignoring the fact that we've already addressed this numerous times. So
Zeev, while I appreciate your interest and welcome you to participate,
please take another look at the previous posts in this thread, because we
have already addressed your concerns ad nauseum and have since moved-on. I
do not want us to get dragged back into grinding our wheels in the mud on
that. Thank you for your understanding.
--Kris
Guys,
I've followed this thread silently so far, and I'm wondering what changed
over the last ~1.5years that warrants a new discussion into that matter.
I think the previous discussion ended with a pretty clear directive that
strict typing has no place in PHP. Rasmus said about the proposal back
then "They aren't hints. It is strict typing and in its current form I
would ask you guys not to call the 5.4 release PHP." - which put in one
sentence what several others (myself included) put in many more words. So
the 'strong'/'firm'/'strict'/whatnot version of what is being discussed
here, should probably not be discussed at all. We've been through it, and
rejected it.Back when we rejected strict typing, we also 'killed' the other RFC[*]
that was born out of that old discussion - the 'weak' auto-conversion RFC.
If I recall correctly, it was for two reasons - one was that the
proponents of the strict typing said they'll firmly object weak typing, and
the other is that this RFC still had some issues that didn't seem obvious
to hammer out (main one I recall is that sticking to PHP's standard type
juggling rules meant that feature wasn't very useful, and we didn't feel
very comfortable introducing brand new type juggling rules just for that
feature). If you want to revive that discussion, I suggest you take a look
at that RFC - confine yourselves to only work on stuff that stands a chance
to get accepted (no strict typing) - and try to come up with good answers
to the open questions. No point in redoing the whole discussion from
scratch.Zeev
[*]https://wiki.php.net/rfc/typecheckingstrictandweak
-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Tuesday, February 28, 2012 11:58 PM
To: John Crenshaw
Cc: Richard Lynch; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hintingErr sorry yes John is correct. I wasn't paying close enough attention.
Here's my vision of how that progression would look:
$a = "1"; // Current kosher unchanged.
weak int $a = "1"; // Converts to 1. No error thrown.
strong int $a = "1"; // Converts to 1. May or may not throw an error
(I'm still on
the fence).$a = "blah"; // Current kosher unchanged.
weak int $a = "blah"; // Throws E_x error level.
strong int $a = "blah"; // Throws E_y error level.Where E_y > E_x.
--Kris
On Tue, Feb 28, 2012 at 1:52 PM, John Crenshaw
johncrenshaw@priacta.comwrote:No, In the example given there's an error on int $a = "1". There
should be no error because this juggles fine.John Crenshaw
Priacta, inc.-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Tuesday, February 28, 2012 4:47 PM
To: Richard Lynch
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting@Richard That's fairly close to what I'm thinking, yes. But there
seems to be a diverse range of ideas bouncing around right now, so at
present it's all in flux.--Kris
I think this is the main reason for differentiating between
"strong"
(or
whatever word is appropriate) and "weak." The developer may very
well want their script to blow-up in such a case.I believe I actually "get it" now...
You want 3 layers:
$a = "1"; //current kosher unchanged weak int $a = "1"; // some E_x
error level strong int $a = "1"; // some E_y error level where E_y >
E_xIs that a correct summation?
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id
=F
S9NLTNEEKWBE--
To unsubscribe,
visit: http://www.php.net/unsub.php
Kris,
If we've agreed that strict typing is bad, why is it even showing on the discussion here? Calling it 'firm' or 'strong' doesn't make a difference. If it errors out or throws an exception (which BTW is out of the question for a language feature), it's strict typing, regardless of naming.
Thanks for pointing me to the voting procedure that I helped author. Are you essentially telling us we all have to waste our time again just because 6 months have passed? That alone might be reason enough to turn the OR in there into an AND and shut down that loophole. The rationale behind that time period was to allow for cases where there was an 'almost' majority. Here, the proposal stands no chance. The only reason you're not seeing anybody from the core devs responding is because they're tired of the Nth incarnation of the same discussion happening again with zero new ideas.
If you can show why it makes sense to revive the discussion based on the 2nd bullet, that is:
The author(s) make substantial changes to the proposal. While it's impossible to put clear definitions on what constitutes 'substantial' changes, they should be material enough so that they'll significantly effect the outcome of another vote.
... then it's worth discussing. Nothing I saw in this thread falls under that category, as far as I can tell.
Let's put it to rest.
Zeev
From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Wednesday, February 29, 2012 11:18 PM
To: Zeev Suraski
Cc: John Crenshaw; Richard Lynch; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
....Aaaaaand here we go again. Every few days it seems, somebody jumps into this thread and reminds us that strict typing is a bad idea, despite the fact that we've already all agreed on that point about a gazillion times.
As for past RFC's, I would recommend you review the voting procedure. If an RFC is rejected, the policy does allow it to be re-introduced after 6 months. While we're not actually reviving a previously rejected RFC since we're discussing a different approach, even if you were to apply that to the broader conceptual level, this discussion is still perfectly kosher since, as you said, that rejection happened 1.5 years ago (3 times the required period).
Sorry if my tone is a bit frustrated, but I think we're all a bit annoyed at this repetitive pattern by now. We start finding common ground and making progress, then somebody new makes a post about the evils of strict typing and questioning why we're talking about this, obviously completely ignoring the fact that we've already addressed this numerous times. So Zeev, while I appreciate your interest and welcome you to participate, please take another look at the previous posts in this thread, because we have already addressed your concerns ad nauseum and have since moved-on. I do not want us to get dragged back into grinding our wheels in the mud on that. Thank you for your understanding.
--Kris
Guys,
I've followed this thread silently so far, and I'm wondering what changed over the last ~1.5years that warrants a new discussion into that matter.
I think the previous discussion ended with a pretty clear directive that strict typing has no place in PHP. Rasmus said about the proposal back then "They aren't hints. It is strict typing and in its current form I would ask you guys not to call the 5.4 release PHP." - which put in one sentence what several others (myself included) put in many more words. So the 'strong'/'firm'/'strict'/whatnot version of what is being discussed here, should probably not be discussed at all. We've been through it, and rejected it.
Back when we rejected strict typing, we also 'killed' the other RFC[*] that was born out of that old discussion - the 'weak' auto-conversion RFC. If I recall correctly, it was for two reasons - one was that the proponents of the strict typing said they'll firmly object weak typing, and the other is that this RFC still had some issues that didn't seem obvious to hammer out (main one I recall is that sticking to PHP's standard type juggling rules meant that feature wasn't very useful, and we didn't feel very comfortable introducing brand new type juggling rules just for that feature). If you want to revive that discussion, I suggest you take a look at that RFC - confine yourselves to only work on stuff that stands a chance to get accepted (no strict typing) - and try to come up with good answers to the open questions. No point in redoing the whole discussion from scratch.
Zeev
[*]https://wiki.php.net/rfc/typecheckingstrictandweak
-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.commailto:kris.craig@gmail.com]
Sent: Tuesday, February 28, 2012 11:58 PM
To: John Crenshaw
Cc: Richard Lynch; internals@lists.php.netmailto:internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hintingErr sorry yes John is correct. I wasn't paying close enough attention.
Here's my vision of how that progression would look:
$a = "1"; // Current kosher unchanged.
weak int $a = "1"; // Converts to 1. No error thrown.
strong int $a = "1"; // Converts to 1. May or may not throw an error (I'm still on
the fence).$a = "blah"; // Current kosher unchanged.
weak int $a = "blah"; // Throws E_x error level.
strong int $a = "blah"; // Throws E_y error level.Where E_y > E_x.
--Kris
On Tue, Feb 28, 2012 at 1:52 PM, John Crenshaw
<johncrenshaw@priacta.commailto:johncrenshaw@priacta.com>wrote:No, In the example given there's an error on int $a = "1". There
should be no error because this juggles fine.John Crenshaw
Priacta, inc.-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.commailto:kris.craig@gmail.com]
Sent: Tuesday, February 28, 2012 4:47 PM
To: Richard Lynch
Cc: internals@lists.php.netmailto:internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting@Richard That's fairly close to what I'm thinking, yes. But there
seems to be a diverse range of ideas bouncing around right now, so at
present it's all in flux.--Kris
I think this is the main reason for differentiating between "strong"
(or
whatever word is appropriate) and "weak." The developer may very
well want their script to blow-up in such a case.I believe I actually "get it" now...
You want 3 layers:
$a = "1"; //current kosher unchanged weak int $a = "1"; // some E_x
error level strong int $a = "1"; // some E_y error level where E_y >
E_xIs that a correct summation?
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id
=F
S9NLTNEEKWBE--
To unsubscribe,
visit: http://www.php.net/unsub.php
Responses inline.
--Kris
Kris,****
If we’ve agreed that strict typing is bad, why is it even showing on the
discussion here? Calling it ‘firm’ or ‘strong’ doesn’t make a difference.
If it errors out or throws an exception (which BTW is out of the question
for a language feature), it’s strict typing, regardless of naming.
That is a form of cognitive dissonance, a logical fallacy. More
colloquially known as an "either or argument."
Everyone agrees that strict C-like typing is not tenable. We've moved past
that and what's being proposed now does not rise to that level.
Thanks for pointing me to the voting procedure that I helped author.
You're welcome.
Are you essentially telling us we all have to waste our time again just
because 6 months have passed?
Yes. Though given how many people have shown an interest in this thread, I
would challenge your assertion that it is a waste of time. If you feel as
though it's a waste of your time, then don't waste your time. But that
doesn't give you the right to demand that we cease talking about it just
because you don't think it's a worthy discussion.
That alone might be reason enough to turn the OR in there into an AND
and shut down that loophole.
You're free to introduce a new RFC for that, but don't be surprised when I
and probably a number of others campaign heavily and tirelessly against
it. I don't think most people would agree with such a totalitarian
approach designed to silence dissenting views from being introduced and
discussed.
The rationale behind that time period was to allow for cases where there
was an ‘almost’ majority. Here, the proposal stands no chance. The only
reason you’re not seeing anybody from the core devs responding is because
they’re tired of the Nth incarnation of the same discussion happening again
with zero new ideas.
Please refer to the Wikipedia link I posted above pertaining to "weasel
words."
Just because a conceptually similar proposal failed two years ago doesn't
mean the discussion we're having now won't have any support.
If you can show why it makes sense to revive the discussion based on the 2
nd bullet, that is:****The author(s) make substantial changes to the proposal. While it's
impossible to put clear definitions on what constitutes 'substantial'
changes, they should be material enough so that they'll significantly
effect the outcome of another vote.****
… then it’s worth discussing. Nothing I saw in this thread falls under
that category, as far as I can tell.
I disagree. A number of ideas have been put forth that differ from
previous proposals. Just because you don't think they differ enough does
not mean you can unilaterally declare that this discussion must end.
Besides, as you said, such a standard would be completely arbitrary and
open to interpretation. It would ultimately be something that would have
to come down to a vote (unless you're planning on being the one who gets to
decide for the rest of us what's substantial and what's not), which would
render the whole argument pointless anyway, since it would essentially be a
vote on whether or not we should have a vote. That's how the United States
Congress typically operates, and we all know how effective they are....
Let’s put it to rest.
This issue isn't going away. Again, we've already addressed this in
previous posts. You may not want to discuss it, and there may be people
who share your sentiment, but that does not give you the authority to shut
down this conversation or declare that you're going to change the RFC rules
so that we can't vote on this. If that's not what you were proposing, then
please accept my apologies for the misunderstanding. Either way, I've
already promised to push back hard against any efforts to silence the
discussion this time around, and I intend to honor that promise.
I am still in favor of ultimately moving this conversation to a separate
location if people like Zeev are just tired of having this in their
inboxes. Plus it would give those of us who are actually interested in
this a place to brainstorm without old fear tactics periodically being
reintroduced in an effort to derail the conversation. I'll investigate
such options as soon as I have some spare moments. It's been a busy week.
=)
Zeev****
From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Wednesday, February 29, 2012 11:18 PM
To: Zeev Suraski
Cc: John Crenshaw; Richard Lynch; internals@lists.php.netSubject: Re: [PHP-DEV] Scalar type hinting****
....Aaaaaand here we go again. Every few days it seems, somebody jumps
into this thread and reminds us that strict typing is a bad idea, despite
the fact that we've already all agreed on that point about a gazillion
times.As for past RFC's, I would recommend you review the voting procedure. If
an RFC is rejected, the policy does allow it to be re-introduced after 6
months. While we're not actually reviving a previously rejected RFC since
we're discussing a different approach, even if you were to apply that to
the broader conceptual level, this discussion is still perfectly kosher
since, as you said, that rejection happened 1.5 years ago (3 times the
required period).Sorry if my tone is a bit frustrated, but I think we're all a bit annoyed
at this repetitive pattern by now. We start finding common ground and
making progress, then somebody new makes a post about the evils of strict
typing and questioning why we're talking about this, obviously completely
ignoring the fact that we've already addressed this numerous times. So
Zeev, while I appreciate your interest and welcome you to participate,
please take another look at the previous posts in this thread, because we
have already addressed your concerns ad nauseum and have since moved-on. I
do not want us to get dragged back into grinding our wheels in the mud on
that. Thank you for your understanding.--Kris
On Wed, Feb 29, 2012 at 1:09 PM, Zeev Suraski zeev@zend.com wrote:****
Guys,
I've followed this thread silently so far, and I'm wondering what changed
over the last ~1.5years that warrants a new discussion into that matter.
I think the previous discussion ended with a pretty clear directive that
strict typing has no place in PHP. Rasmus said about the proposal back
then "They aren't hints. It is strict typing and in its current form I
would ask you guys not to call the 5.4 release PHP." - which put in one
sentence what several others (myself included) put in many more words. So
the 'strong'/'firm'/'strict'/whatnot version of what is being discussed
here, should probably not be discussed at all. We've been through it, and
rejected it.Back when we rejected strict typing, we also 'killed' the other RFC[*]
that was born out of that old discussion - the 'weak' auto-conversion RFC.
If I recall correctly, it was for two reasons - one was that the
proponents of the strict typing said they'll firmly object weak typing, and
the other is that this RFC still had some issues that didn't seem obvious
to hammer out (main one I recall is that sticking to PHP's standard type
juggling rules meant that feature wasn't very useful, and we didn't feel
very comfortable introducing brand new type juggling rules just for that
feature). If you want to revive that discussion, I suggest you take a look
at that RFC - confine yourselves to only work on stuff that stands a chance
to get accepted (no strict typing) - and try to come up with good answers
to the open questions. No point in redoing the whole discussion from
scratch.Zeev
[]https://wiki.php.net/rfc/typecheckingstrictandweak***
-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]****Sent: Tuesday, February 28, 2012 11:58 PM
To: John Crenshaw****Cc: Richard Lynch; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
Err sorry yes John is correct. I wasn't paying close enough attention.
Here's my vision of how that progression would look:
$a = "1"; // Current kosher unchanged.
weak int $a = "1"; // Converts to 1. No error thrown.****strong int $a = "1"; // Converts to 1. May or may not throw an error
(I'm still on
the fence).
$a = "blah"; // Current kosher unchanged.
weak int $a = "blah"; // Throws E_x error level.
strong int $a = "blah"; // Throws E_y error level.Where E_y > E_x.
--Kris
On Tue, Feb 28, 2012 at 1:52 PM, John Crenshaw
johncrenshaw@priacta.comwrote:No, In the example given there's an error on int $a = "1". There
should be no error because this juggles fine.John Crenshaw
Priacta, inc.****-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]****Sent: Tuesday, February 28, 2012 4:47 PM
To: Richard Lynch
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
@Richard That's fairly close to what I'm thinking, yes. But there
seems to be a diverse range of ideas bouncing around right now, so at
present it's all in flux.--Kris
I think this is the main reason for differentiating between
"strong"
(or
whatever word is appropriate) and "weak." The developer may very
well want their script to blow-up in such a case.I believe I actually "get it" now...
You want 3 layers:
$a = "1"; //current kosher unchanged weak int $a = "1"; // some E_x
error level strong int $a = "1"; // some E_y error level where E_y >
E_xIs that a correct summation?****
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id
=F
S9NLTNEEKWBE--
To unsubscribe,
visit: http://www.php.net/unsub.php
Kris i have a question for you - who will implement a test patch? Previous
tries failed not because no one wanted, but because it was damn hard and
tricky. And ofcourse there was resistance against strict type hinting. Mine
included. I doubt any of the last timeinvolved will be willing to do that
again. So that is it: who has the skill, knowlage and will to do that
knowing there is very big chance it will be rejected?
I would challenge the preconceived notion that it's likely to be rejected.
It winds up being a form of circular logic. For example, you argued that
previous tries failed to be approved because nobody wanted to do the work.
But then you said that nobody wants to do the work because it has failed to
be approved previously. Circle complete. It's also worth noting that
opinions and sentiments do change over time, even in just a couple years.
Honestly, the "how" question is very important. But we can't even go there
yet when we still haven't solidly figured out the "what". I do agree that
the logistics of actually getting it done should be evaluated carefully
before an RFC is voted on. However, right now I think that's a bit
premature since we're nowhere close to that stage at this point. We don't
even have a draft RFC yet, much less something that can be voted on or have
test patches created for.
--Kris
On Wed, Feb 29, 2012 at 2:24 PM, Arvids Godjuks arvids.godjuks@gmail.comwrote:
Kris i have a question for you - who will implement a test patch? Previous
tries failed not because no one wanted, but because it was damn hard and
tricky. And ofcourse there was resistance against strict type hinting. Mine
included. I doubt any of the last timeinvolved will be willing to do that
again. So that is it: who has the skill, knowlage and will to do that
knowing there is very big chance it will be rejected?
Please.read my emails carefuly. What i said is last time the work has been
done, and two different patches have been developed and iterated. But
dificulties in implementation and strong resistance from the devs and
comunity got it killed. I actually had a post on our biggest russian
speaking IT resource and results shown that majority of comunity was
against strict type hinting - it does not fit PHP philosophy. Simple as
that.
Thats all, if you cant unders
I agree. I'm against strict type hinting as well. Of course, nobody here
is suggesting that we should go with strict typing, so it's a moot question
anyway.
--Kris
On Wed, Feb 29, 2012 at 2:35 PM, Arvids Godjuks arvids.godjuks@gmail.comwrote:
Please.read my emails carefuly. What i said is last time the work has been
done, and two different patches have been developed and iterated. But
dificulties in implementation and strong resistance from the devs and
comunity got it killed. I actually had a post on our biggest russian
speaking IT resource and results shown that majority of comunity was
against strict type hinting - it does not fit PHP philosophy. Simple as
that.
Thats all, if you cant unders
Kris,
Responses aren't inline. I'll go back to the mode that most other core devs are employing right now and ignore it for the waste of time that it is. I won't ignore it if it ever comes to a vote, nor will the others.
Troll away.
Zeev
From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Thursday, March 01, 2012 12:16 AM
To: Zeev Suraski
Cc: John Crenshaw; Richard Lynch; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
Responses inline.
--Kris
Kris,
If we've agreed that strict typing is bad, why is it even showing on the discussion here? Calling it 'firm' or 'strong' doesn't make a difference. If it errors out or throws an exception (which BTW is out of the question for a language feature), it's strict typing, regardless of naming.
That is a form of cognitive dissonance, a logical fallacy. More colloquially known as an "either or argument."
Everyone agrees that strict C-like typing is not tenable. We've moved past that and what's being proposed now does not rise to that level.
Thanks for pointing me to the voting procedure that I helped author.
You're welcome.
Are you essentially telling us we all have to waste our time again just because 6 months have passed?
Yes. Though given how many people have shown an interest in this thread, I would challenge your assertion that it is a waste of time. If you feel as though it's a waste of your time, then don't waste your time. But that doesn't give you the right to demand that we cease talking about it just because you don't think it's a worthy discussion.
That alone might be reason enough to turn the OR in there into an AND and shut down that loophole.
You're free to introduce a new RFC for that, but don't be surprised when I and probably a number of others campaign heavily and tirelessly against it. I don't think most people would agree with such a totalitarian approach designed to silence dissenting views from being introduced and discussed.
The rationale behind that time period was to allow for cases where there was an 'almost' majority. Here, the proposal stands no chance. The only reason you're not seeing anybody from the core devs responding is because they're tired of the Nth incarnation of the same discussion happening again with zero new ideas.
Please refer to the Wikipedia link I posted above pertaining to "weasel words."
Just because a conceptually similar proposal failed two years ago doesn't mean the discussion we're having now won't have any support.
If you can show why it makes sense to revive the discussion based on the 2nd bullet, that is:
The author(s) make substantial changes to the proposal. While it's impossible to put clear definitions on what constitutes 'substantial' changes, they should be material enough so that they'll significantly effect the outcome of another vote.
... then it's worth discussing. Nothing I saw in this thread falls under that category, as far as I can tell.
I disagree. A number of ideas have been put forth that differ from previous proposals. Just because you don't think they differ enough does not mean you can unilaterally declare that this discussion must end. Besides, as you said, such a standard would be completely arbitrary and open to interpretation. It would ultimately be something that would have to come down to a vote (unless you're planning on being the one who gets to decide for the rest of us what's substantial and what's not), which would render the whole argument pointless anyway, since it would essentially be a vote on whether or not we should have a vote. That's how the United States Congress typically operates, and we all know how effective they are....
Let's put it to rest.
This issue isn't going away. Again, we've already addressed this in previous posts. You may not want to discuss it, and there may be people who share your sentiment, but that does not give you the authority to shut down this conversation or declare that you're going to change the RFC rules so that we can't vote on this. If that's not what you were proposing, then please accept my apologies for the misunderstanding. Either way, I've already promised to push back hard against any efforts to silence the discussion this time around, and I intend to honor that promise.
I am still in favor of ultimately moving this conversation to a separate location if people like Zeev are just tired of having this in their inboxes. Plus it would give those of us who are actually interested in this a place to brainstorm without old fear tactics periodically being reintroduced in an effort to derail the conversation. I'll investigate such options as soon as I have some spare moments. It's been a busy week. =)
Zeev
From: Kris Craig [mailto:kris.craig@gmail.commailto:kris.craig@gmail.com]
Sent: Wednesday, February 29, 2012 11:18 PM
To: Zeev Suraski
Cc: John Crenshaw; Richard Lynch; internals@lists.php.netmailto:internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
....Aaaaaand here we go again. Every few days it seems, somebody jumps into this thread and reminds us that strict typing is a bad idea, despite the fact that we've already all agreed on that point about a gazillion times.
As for past RFC's, I would recommend you review the voting procedure. If an RFC is rejected, the policy does allow it to be re-introduced after 6 months. While we're not actually reviving a previously rejected RFC since we're discussing a different approach, even if you were to apply that to the broader conceptual level, this discussion is still perfectly kosher since, as you said, that rejection happened 1.5 years ago (3 times the required period).
Sorry if my tone is a bit frustrated, but I think we're all a bit annoyed at this repetitive pattern by now. We start finding common ground and making progress, then somebody new makes a post about the evils of strict typing and questioning why we're talking about this, obviously completely ignoring the fact that we've already addressed this numerous times. So Zeev, while I appreciate your interest and welcome you to participate, please take another look at the previous posts in this thread, because we have already addressed your concerns ad nauseum and have since moved-on. I do not want us to get dragged back into grinding our wheels in the mud on that. Thank you for your understanding.
--Kris
Guys,
I've followed this thread silently so far, and I'm wondering what changed over the last ~1.5years that warrants a new discussion into that matter.
I think the previous discussion ended with a pretty clear directive that strict typing has no place in PHP. Rasmus said about the proposal back then "They aren't hints. It is strict typing and in its current form I would ask you guys not to call the 5.4 release PHP." - which put in one sentence what several others (myself included) put in many more words. So the 'strong'/'firm'/'strict'/whatnot version of what is being discussed here, should probably not be discussed at all. We've been through it, and rejected it.
Back when we rejected strict typing, we also 'killed' the other RFC[*] that was born out of that old discussion - the 'weak' auto-conversion RFC. If I recall correctly, it was for two reasons - one was that the proponents of the strict typing said they'll firmly object weak typing, and the other is that this RFC still had some issues that didn't seem obvious to hammer out (main one I recall is that sticking to PHP's standard type juggling rules meant that feature wasn't very useful, and we didn't feel very comfortable introducing brand new type juggling rules just for that feature). If you want to revive that discussion, I suggest you take a look at that RFC - confine yourselves to only work on stuff that stands a chance to get accepted (no strict typing) - and try to come up with good answers to the open questions. No point in redoing the whole discussion from scratch.
Zeev
[*]https://wiki.php.net/rfc/typecheckingstrictandweak
-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.commailto:kris.craig@gmail.com]
Sent: Tuesday, February 28, 2012 11:58 PM
To: John Crenshaw
Cc: Richard Lynch; internals@lists.php.netmailto:internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hintingErr sorry yes John is correct. I wasn't paying close enough attention.
Here's my vision of how that progression would look:
$a = "1"; // Current kosher unchanged.
weak int $a = "1"; // Converts to 1. No error thrown.
strong int $a = "1"; // Converts to 1. May or may not throw an error (I'm still on
the fence).$a = "blah"; // Current kosher unchanged.
weak int $a = "blah"; // Throws E_x error level.
strong int $a = "blah"; // Throws E_y error level.Where E_y > E_x.
--Kris
On Tue, Feb 28, 2012 at 1:52 PM, John Crenshaw
<johncrenshaw@priacta.commailto:johncrenshaw@priacta.com>wrote:No, In the example given there's an error on int $a = "1". There
should be no error because this juggles fine.John Crenshaw
Priacta, inc.-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.commailto:kris.craig@gmail.com]
Sent: Tuesday, February 28, 2012 4:47 PM
To: Richard Lynch
Cc: internals@lists.php.netmailto:internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting@Richard That's fairly close to what I'm thinking, yes. But there
seems to be a diverse range of ideas bouncing around right now, so at
present it's all in flux.--Kris
I think this is the main reason for differentiating between "strong"
(or
whatever word is appropriate) and "weak." The developer may very
well want their script to blow-up in such a case.I believe I actually "get it" now...
You want 3 layers:
$a = "1"; //current kosher unchanged weak int $a = "1"; // some E_x
error level strong int $a = "1"; // some E_y error level where E_y >
E_xIs that a correct summation?
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id
=F
S9NLTNEEKWBE--
To unsubscribe,
visit: http://www.php.net/unsub.php
In other words: "I'm not gonna respond to your arguments because you're a
troll. None of us smart people agree with you. Nyah nyah nyah I can't
hear you nyah nyah nyah!"
My response: sticks tongue out.... So there. ;P
Now that that's settled, where were we?....
Ok, looks like we left off at Lester expressing concern over integers >1
throwing an error on booleans. If checking for that would be problematic
then I have no problem letting it fail gracefully, though in an ideal world
my preference would be to see something thrown in such an event.
--Kris
Kris,****
Responses aren’t inline. I’ll go back to the mode that most other core
devs are employing right now and ignore it for the waste of time that it
is. I won’t ignore it if it ever comes to a vote, nor will the others.***
Troll away.****
Zeev****
From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Thursday, March 01, 2012 12:16 AMTo: Zeev Suraski
Cc: John Crenshaw; Richard Lynch; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting****
Responses inline.
--Kris
On Wed, Feb 29, 2012 at 1:49 PM, Zeev Suraski zeev@zend.com wrote:****
Kris,****
If we’ve agreed that strict typing is bad, why is it even showing on the
discussion here? Calling it ‘firm’ or ‘strong’ doesn’t make a difference.
If it errors out or throws an exception (which BTW is out of the question
for a language feature), it’s strict typing, regardless of naming.****That is a form of cognitive dissonance, a logical fallacy. More
colloquially known as an "either or argument."Everyone agrees that strict C-like typing is not tenable. We've moved
past that and what's being proposed now does not rise to that level.
Thanks for pointing me to the voting procedure that I helped author. ****
You're welcome.
Are you essentially telling us we all have to waste our time again just
because 6 months have passed?****Yes. Though given how many people have shown an interest in this thread,
I would challenge your assertion that it is a waste of time. If you feel
as though it's a waste of your time, then don't waste your time. But
that doesn't give you the right to demand that we cease talking about it
just because you don't think it's a worthy discussion.
That alone might be reason enough to turn the OR in there into an AND
and shut down that loophole.****You're free to introduce a new RFC for that, but don't be surprised when I
and probably a number of others campaign heavily and tirelessly against
it. I don't think most people would agree with such a totalitarian
approach designed to silence dissenting views from being introduced and
discussed.****The rationale behind that time period was to allow for cases where
there was an ‘almost’ majority. Here, the proposal stands no chance. The
only reason you’re not seeing anybody from the core devs responding is
because they’re tired of the Nth incarnation of the same discussion
happening again with zero new ideas.****Please refer to the Wikipedia link I posted above pertaining to "weasel
words."Just because a conceptually similar proposal failed two years ago doesn't
mean the discussion we're having now won't have any support.
If you can show why it makes sense to revive the discussion based on the 2
nd bullet, that is:****The author(s) make substantial changes to the proposal. While it's
impossible to put clear definitions on what constitutes 'substantial'
changes, they should be material enough so that they'll significantly
effect the outcome of another vote.****
… then it’s worth discussing. Nothing I saw in this thread falls under
that category, as far as I can tell.****I disagree. A number of ideas have been put forth that differ from
previous proposals. Just because you don't think they differ enough
does not mean you can unilaterally declare that this discussion must end.
Besides, as you said, such a standard would be completely arbitrary and
open to interpretation. It would ultimately be something that would have
to come down to a vote (unless you're planning on being the one who gets to
decide for the rest of us what's substantial and what's not), which would
render the whole argument pointless anyway, since it would essentially be a
vote on whether or not we should have a vote. That's how the United States
Congress typically operates, and we all know how effective they are....***
Let’s put it to rest.****
This issue isn't going away. Again, we've already addressed this in
previous posts. You may not want to discuss it, and there may be people
who share your sentiment, but that does not give you the authority to shut
down this conversation or declare that you're going to change the RFC rules
so that we can't vote on this. If that's not what you were proposing, then
please accept my apologies for the misunderstanding. Either way, I've
already promised to push back hard against any efforts to silence the
discussion this time around, and I intend to honor that promise.I am still in favor of ultimately moving this conversation to a separate
location if people like Zeev are just tired of having this in their
inboxes. Plus it would give those of us who are actually interested in
this a place to brainstorm without old fear tactics periodically being
reintroduced in an effort to derail the conversation. I'll investigate
such options as soon as I have some spare moments. It's been a busy week.
=)****
Zeev****
From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Wednesday, February 29, 2012 11:18 PM
To: Zeev Suraski
Cc: John Crenshaw; Richard Lynch; internals@lists.php.net****Subject: Re: [PHP-DEV] Scalar type hinting****
....Aaaaaand here we go again. Every few days it seems, somebody jumps
into this thread and reminds us that strict typing is a bad idea, despite
the fact that we've already all agreed on that point about a gazillion
times.As for past RFC's, I would recommend you review the voting procedure. If
an RFC is rejected, the policy does allow it to be re-introduced after 6
months. While we're not actually reviving a previously rejected RFC since
we're discussing a different approach, even if you were to apply that to
the broader conceptual level, this discussion is still perfectly kosher
since, as you said, that rejection happened 1.5 years ago (3 times the
required period).Sorry if my tone is a bit frustrated, but I think we're all a bit annoyed
at this repetitive pattern by now. We start finding common ground and
making progress, then somebody new makes a post about the evils of strict
typing and questioning why we're talking about this, obviously completely
ignoring the fact that we've already addressed this numerous times. So
Zeev, while I appreciate your interest and welcome you to participate,
please take another look at the previous posts in this thread, because we
have already addressed your concerns ad nauseum and have since moved-on. I
do not want us to get dragged back into grinding our wheels in the mud on
that. Thank you for your understanding.--Kris****
On Wed, Feb 29, 2012 at 1:09 PM, Zeev Suraski zeev@zend.com wrote:****
Guys,
I've followed this thread silently so far, and I'm wondering what changed
over the last ~1.5years that warrants a new discussion into that matter.
I think the previous discussion ended with a pretty clear directive that
strict typing has no place in PHP. Rasmus said about the proposal back
then "They aren't hints. It is strict typing and in its current form I
would ask you guys not to call the 5.4 release PHP." - which put in one
sentence what several others (myself included) put in many more words. So
the 'strong'/'firm'/'strict'/whatnot version of what is being discussed
here, should probably not be discussed at all. We've been through it, and
rejected it.Back when we rejected strict typing, we also 'killed' the other RFC[*]
that was born out of that old discussion - the 'weak' auto-conversion RFC.
If I recall correctly, it was for two reasons - one was that the
proponents of the strict typing said they'll firmly object weak typing, and
the other is that this RFC still had some issues that didn't seem obvious
to hammer out (main one I recall is that sticking to PHP's standard type
juggling rules meant that feature wasn't very useful, and we didn't feel
very comfortable introducing brand new type juggling rules just for that
feature). If you want to revive that discussion, I suggest you take a look
at that RFC - confine yourselves to only work on stuff that stands a chance
to get accepted (no strict typing) - and try to come up with good answers
to the open questions. No point in redoing the whole discussion from
scratch.Zeev
[]https://wiki.php.net/rfc/typecheckingstrictandweak***
-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]****Sent: Tuesday, February 28, 2012 11:58 PM
To: John Crenshaw****Cc: Richard Lynch; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
Err sorry yes John is correct. I wasn't paying close enough attention.
Here's my vision of how that progression would look:
$a = "1"; // Current kosher unchanged.
weak int $a = "1"; // Converts to 1. No error thrown.****strong int $a = "1"; // Converts to 1. May or may not throw an error
(I'm still on
the fence).
$a = "blah"; // Current kosher unchanged.
weak int $a = "blah"; // Throws E_x error level.
strong int $a = "blah"; // Throws E_y error level.Where E_y > E_x.
--Kris
On Tue, Feb 28, 2012 at 1:52 PM, John Crenshaw
johncrenshaw@priacta.comwrote:No, In the example given there's an error on int $a = "1". There
should be no error because this juggles fine.John Crenshaw
Priacta, inc.****-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]****Sent: Tuesday, February 28, 2012 4:47 PM
To: Richard Lynch
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
@Richard That's fairly close to what I'm thinking, yes. But there
seems to be a diverse range of ideas bouncing around right now, so at
present it's all in flux.--Kris
I think this is the main reason for differentiating between
"strong"
(or
whatever word is appropriate) and "weak." The developer may very
well want their script to blow-up in such a case.I believe I actually "get it" now...
You want 3 layers:
$a = "1"; //current kosher unchanged weak int $a = "1"; // some E_x
error level strong int $a = "1"; // some E_y error level where E_y >
E_xIs that a correct summation?****
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id
=F
S9NLTNEEKWBE--
To unsubscribe,
visit: http://www.php.net/unsub.php
Zeev Suraski zeev@zend.com wrote:
I'll go back to the mode that most other
core devs are employing right now and ignore it for the waste of time
that it is. I won't ignore it if it ever comes to a vote, nor will
the others.
Quite right. Even though I'd like some form of typehints it makes no sense to talk about it every six months. Back to lurking and ready to vote against if it shows up.
If you think it's a good idea, then why vote against it? Seems kinda
strange to me.
This issue isn't going to go away. If you really want it to stop coming up
every 6 months because people are constantly requesting it, maybe we
should find a way to implement something that would appease this concern,
since the "be a dismissive prick" strategy obviously isn't working (that
last part wasn't directed at you personally, Derick). =)
--Kris
Zeev Suraski zeev@zend.com wrote:
I'll go back to the mode that most other
core devs are employing right now and ignore it for the waste of time
that it is. I won't ignore it if it ever comes to a vote, nor will
the others.
Quite right. Even though I'd like some form of typehints it makes no sense
to talk about it every six months. Back to lurking and ready to vote
against if it shows up.
Kris,
If we've agreed that strict typing is bad, why is it even showing on the
discussion here? Calling it 'firm' or 'strong' doesn't make a difference.
If it errors out or throws an exception (which BTW is out of the question
for a language feature), it's strict typing, regardless of naming.
Can someone point to what they perceive to be an appropriate definition of
strict typing is (online or in a CS book?) It's one thing to say strict
typing is bad, but I'm not confident that everyone is talking about the
same thing.
My books on programming language design don't specifically speak to
"strict" typing (e.g., Language Implementation Patterns, Programming
Language Pragmatics, etc.) I've found some Actionscript-specific writings
and a few discussions involving Ruby (although my books on Ruby don't speak
of "strict" typing), and discussions on variable levels of type checking:
http://en.wikipedia.org/wiki/Type_system#Variable_levels_of_type_checking
What is the operationalized definition that the core developers want
utilized?
Thank you very much,
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
If it errors out or throws an exception, it's strict typing, regardless of naming.
Actually, for purposes of this discussion, "strict" is defined. It means "PHP complains about (function(int $n){})('1'), even though it could have easily converted it." The majority of arguments in the past, and especially those that have caused the typing discussions to fall apart, have centered around reasons why this sort of typing is bad. Strict, by this definition, is totally off the table in this discussion. Period.
With respect to E_RECOVERABLE_ERROR, nobody seems especially attached to this, except that it is consistent with current type hints, so it is the logical choice. A consistent alternative would be a new E_TYPE error (and convert existing type hints to use that), but that would be a BC break and expands the scope of the proposal more than I think some people are comfortable with (myself included).
Are you essentially telling us we all have to waste our time again just because 6 months have passed?
No, we're discussing this again because for the first time we have a set of terminology that we can use to explain how this is different from the terror that has primarily been avoided in the past.
I'm in favor of moving the discussion elsewhere while details are fleshed out and carefully compared to the historical arguments, but so far there has been no consensus on where to move this.
I'll personally resist any attempt to submit anything that isn't substantially different from prior proposals and/or that doesn't include solutions to the problems previously identified.
John Crenshaw
Priacta, Inc.
Now, to rewind a bit past the latest chunk of "I hate this idea" posts....
I'd like to suggest a new term: "strong".
I think it would be better if we could not introduce terms for new
definition if that term is already used in the vocabulary for type systems:
http://en.wikipedia.org/wiki/Strong_typing
This term would be similar to "weak", except with a few key differences:
- Weak would behave very much like Arvids suggested in his earlier
post; i.e. if the variable is an integer but you pass a string (like "aaa")
to it, a warning would be thrown and PHP would attempt to convert it (i.e.
it would become 1).why would "aaa" turn to 1? it would be 0 by the php type juggling rules.
- Strong, on the other hand, would throw a fatal error if you
attempted to pass an incompatible value to an array. Or, to put it another
way, if the "converted" value does not match the original value. For
example, if we're assigning "aaa" to an integer, that would convert to 1;
and, since "1" != "aaa", a fatal error would be thrown. On the other hand,
if you were to pass the string "1" to that integer variable, it would
convert to 1; and, since "1" == 1, there wouldn't be a problem.same error here, it seems that it isn't the typo. putting that aside: so
you say that the type checking would behave the same was as does currently
the == and === operator.
- In both instances, if the converted value matches the original (i.e.
"1" == 1), no warning error would be displayed. Should it perhaps display
a notice though? Or no error at all? I can think of reasonable arguments
on both sides of that question.
I remember seeing that suggestion before, I think that it was proposed more
than once, see
http://marc.info/?l=php-internals&m=128159992610321&w=3
did you read that thread?
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Yeah again sorry about the 1. Another dyslexic moment on this end lol.
I don't care about the specific terminology we use, just so long as it
makes sense and people aren't confusing it with something else. I
differentiated between strong and weak in order to accommodate the looser
functionality that Arvids had suggested. I'm fine with just going with the
stronger approach and calling that weak if that's what everyone wants.
--Kris
Now, to rewind a bit past the latest chunk of "I hate this idea" posts....
I'd like to suggest a new term: "strong".
I think it would be better if we could not introduce terms for new
definition if that term is already used in the vocabulary for type systems:
http://en.wikipedia.org/wiki/Strong_typingThis term would be similar to "weak", except with a few key differences:
- Weak would behave very much like Arvids suggested in his earlier
post; i.e. if the variable is an integer but you pass a string (like "aaa")
to it, a warning would be thrown and PHP would attempt to convert it (i.e.
it would become 1).why would "aaa" turn to 1? it would be 0 by the php type juggling rules.
- Strong, on the other hand, would throw a fatal error if you
attempted to pass an incompatible value to an array. Or, to put it another
way, if the "converted" value does not match the original value. For
example, if we're assigning "aaa" to an integer, that would convert to 1;
and, since "1" != "aaa", a fatal error would be thrown. On the other hand,
if you were to pass the string "1" to that integer variable, it would
convert to 1; and, since "1" == 1, there wouldn't be a problem.same error here, it seems that it isn't the typo. putting that aside: so
you say that the type checking would behave the same was as does currently
the == and === operator.
- In both instances, if the converted value matches the original
(i.e. "1" == 1), no warning error would be displayed. Should it perhaps
display a notice though? Or no error at all? I can think of reasonable
arguments on both sides of that question.I remember seeing that suggestion before, I think that it was proposed
more than once, see
http://marc.info/?l=php-internals&m=128159992610321&w=3
did you read that thread?--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]Now, to rewind a bit past the latest chunk of "I hate this idea" posts....
I'd like to suggest a new term: "strong".
This term would be similar to "weak", except with a few key differences:
...
Some possible examples of how this would look:
weak int $i = "aaa"; // Converts to 1 and throws a warning.
strong int $ii = "aaa"; // Throws a fatal error.
weak int $i = "1"; // Converts to 1.
strong int $ii = "1"; // Converts to 1.--Kris
Can we use a different word (not "strong") at least for just discussion purposes? I worry that "strong" will produce a feeling of intense fear and anxiety in people who have been burned out by strict typing debates. The words "strong" and "strict" are basically inflammatory at this point. In the interest of facilitating a reasonable discussion, I think we should avoid language that is likely to cause discussion to break down.
John Crenshaw
Priacta, Inc.
Would "firm" work better?
--Kris
On Mon, Feb 27, 2012 at 2:27 PM, John Crenshaw johncrenshaw@priacta.comwrote:
-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]Now, to rewind a bit past the latest chunk of "I hate this idea"
posts....I'd like to suggest a new term: "strong".
This term would be similar to "weak", except with a few key differences:
...
Some possible examples of how this would look:
weak int $i = "aaa"; // Converts to 1 and throws a warning.
strong int $ii = "aaa"; // Throws a fatal error.
weak int $i = "1"; // Converts to 1.
strong int $ii = "1"; // Converts to 1.--Kris
Can we use a different word (not "strong") at least for just discussion
purposes? I worry that "strong" will produce a feeling of intense fear and
anxiety in people who have been burned out by strict typing debates. The
words "strong" and "strict" are basically inflammatory at this point. In
the interest of facilitating a reasonable discussion, I think we should
avoid language that is likely to cause discussion to break down.John Crenshaw
Priacta, Inc.
Would "firm" work better?
--Kris
As a working name that would be fine. Of course, if this discussion moves to a sub-group that becomes less critical since it would be less likely for people to jump in the middle and misunderstand the terms.
John Crenshaw
Priacta, Inc.
That's going to get turned into the "real" name if used. I suggest instead:
Gribblefritz.
Gribble typing: the type handling that PHP does today in 5.3/5.4 for
scalar values.
Fritz typing: Some as-yet-undefined type handling that is pickier than
Gribble typing, but how much pickier is unclear.
That, at least, no one has any pre-conceived definition of.
--Larry Garfield
Would "firm" work better?
--Kris
On Mon, Feb 27, 2012 at 2:27 PM, John Crenshawjohncrenshaw@priacta.comwrote:
-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]Now, to rewind a bit past the latest chunk of "I hate this idea"
posts....I'd like to suggest a new term: "strong".
This term would be similar to "weak", except with a few key differences:
...
Some possible examples of how this would look:
weak int $i = "aaa"; // Converts to 1 and throws a warning.
strong int $ii = "aaa"; // Throws a fatal error.
weak int $i = "1"; // Converts to 1.
strong int $ii = "1"; // Converts to 1.--Kris
Can we use a different word (not "strong") at least for just discussion
purposes? I worry that "strong" will produce a feeling of intense fear and
anxiety in people who have been burned out by strict typing debates. The
words "strong" and "strict" are basically inflammatory at this point. In
the interest of facilitating a reasonable discussion, I think we should
avoid language that is likely to cause discussion to break down.John Crenshaw
Priacta, Inc.
No that's like a million times worse, Larry!! Gaylord T. Gribblefritz III
was a serial killer who terrorized the midwest for over 40 years! That
monster murdered me and my entire family! He would sell milk laced with
sleeping pills to school children then take them back to his secluded
ranch, where wealthy businessmen would hunt them for sport. The
International Criminal Court has accused him of committing the worst crimes
against humanity in the last 10,000 years and the Aryan Nations has run
television ads saying this man proves that Hitler really wasn't all that
bad, after all. The Israelis and Palestinians issued a joint statement
condemning this man's violence. The Dalai Lama has gone on record, saying,
"Shit, even I think we should kill this fucking asshole!"
Also, Mr. Gribblefritz (or "Satan's Evil Twin" as they call him in Utah)
recently wrote an op-ed arguing that PHP should be re-written in Fortran
and that its syntax should be changed to resemble QBASIC.
How DARE you insult this list by suggesting THE MOST INFLAMMATORY WORD OF
ALL TIME?!?! You should be Gribblefritzed (you don't want to know) for
even suggesting something so horrible! It's like, FIFTY TRILLION TIMES
WORSE than "strong"!
Other than that, though, I think it's a good idea. ;P
--Kris
On Mon, Feb 27, 2012 at 2:41 PM, Larry Garfield larry@garfieldtech.comwrote:
That's going to get turned into the "real" name if used. I suggest
instead:Gribblefritz.
Gribble typing: the type handling that PHP does today in 5.3/5.4 for
scalar values.Fritz typing: Some as-yet-undefined type handling that is pickier than
Gribble typing, but how much pickier is unclear.That, at least, no one has any pre-conceived definition of.
--Larry Garfield
Would "firm" work better?
--Kris
On Mon, Feb 27, 2012 at 2:27 PM, John Crenshaw<johncrenshaw@priacta.**comjohncrenshaw@priacta.com
wrote:
-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]
Now, to rewind a bit past the latest chunk of "I hate this idea"
posts....
I'd like to suggest a new term: "strong".
This term would be similar to "weak", except with a few key differences:
...
Some possible examples of how this would look:
weak int $i = "aaa"; // Converts to 1 and throws a warning.
strong int $ii = "aaa"; // Throws a fatal error.
weak int $i = "1"; // Converts to 1.
strong int $ii = "1"; // Converts to 1.--Kris
Can we use a different word (not "strong") at least for just discussion
purposes? I worry that "strong" will produce a feeling of intense fear
and
anxiety in people who have been burned out by strict typing debates. The
words "strong" and "strict" are basically inflammatory at this point. In
the interest of facilitating a reasonable discussion, I think we should
avoid language that is likely to cause discussion to break down.John Crenshaw
Priacta, Inc.
Kris, go out for a walk. We don't need fake
stress after the real one :)
Yes, it's midnight here, but who cares?
That you are afraid of going out at night? Because
you had a bad experience with a serial killer?
Oh, well...
PS: This is what I called 'sane weak typing' in the other
thread before you proposed 'strong'...
Lol I'm not worried. Gribblefritz may be a psychopatic serial killer, but
he's also my personal bodyguard. What could possibly go wrong?
--Kris
2012/2/27 Ángel González keisial@gmail.com
Kris, go out for a walk. We don't need fake
stress after the real one :)Yes, it's midnight here, but who cares?
That you are afraid of going out at night? Because
you had a bad experience with a serial killer?
Oh, well...PS: This is what I called 'sane weak typing' in the other
thread before you proposed 'strong'...
+1 what Anthony said.
Guys, seriously. Some of these responses have been downright rude and
inappropriate for a constructive dialogue. Please do not pollute this
thread with cliche, "Just find another language and get out!" posts. It
doesn't add anything to the conversation and instead just creates needless
anger and animosity. It's immature and just makes it look like we're
incapable of having a rational discussion.So, let me outline a list of "arguments" that will carry ZERO weight on
this thread:
- "If you don't like PHP as it is, goto Java (or some other language)!"
- "We've already talked about this before. Therefore, we must never
speak of it again."- "This is impossible. Why? Because I said so. You want evidence?
Fuck you."- "But this would require significant changes to the core source
code! We'd never be able to find enough sacrificial penguins to appease
the gods!"- "Anyone who likes this idea is either stupid or not a 'true' PHP
developer."- "If you disagree with me, it means you haven't done your homework
because I'm always right."- "Strict typing would break everything! What? You're not talking
about C-like strict typing? Sorry, I didn't catch that. Strict typing
would break everything!...."- "I don't care if you've already countered my argument. I'll just
keep repeating myself as if you didn't."Variations of the above statements have been posted ad nauseum. They're
all based on logical fallacies and are not constructive.I'm putting this out there: If anyone posts one or more of the above
arguments yet again on this topic, I will personally extract one of your
kidneys and sell it to a questionable "dog food" company in Shanghai. I
will then openly mock your intellectual laziness and encourage people to
ignore you. ;PI'd love to prove Daniel wrong, but I think he may be on to something....
:\
it is weird that you are calling others rude.
I'm sure you would feel hurt/personally attacked, if somebody would create
a similar list of the little bit twisted arguments of yours.
could we stay on the topic?
another 14 mails to read. :/
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Lol be my guest. You won't have much success though because I have not
relied upon hyperbole and logical fallacies to substantiate my arguments.
On the contrary, my argument thus far can be summarized thusly:
- The issue of type hinting isn't going to go away, otherwise it would
have by now. - This feature, if implemented correctly, won't "break" PHP or
compromise backwards compatibility. - I will push back against any efforts to silence this discussion as has
been done in the past. - If you can't disagree with someone without accusing them of being
ill-informed, disloyal, or just plain dumb; then you're not contributing
anything constructive to this discussion.
There, I just saved you the trouble. =)
--Kris
+1 what Anthony said.
Guys, seriously. Some of these responses have been downright rude and
inappropriate for a constructive dialogue. Please do not pollute this
thread with cliche, "Just find another language and get out!" posts. It
doesn't add anything to the conversation and instead just creates needless
anger and animosity. It's immature and just makes it look like we're
incapable of having a rational discussion.So, let me outline a list of "arguments" that will carry ZERO weight on
this thread:
- "If you don't like PHP as it is, goto Java (or some other
language)!"- "We've already talked about this before. Therefore, we must never
speak of it again."- "This is impossible. Why? Because I said so. You want evidence?
Fuck you."- "But this would require significant changes to the core source
code! We'd never be able to find enough sacrificial penguins to appease
the gods!"- "Anyone who likes this idea is either stupid or not a 'true' PHP
developer."- "If you disagree with me, it means you haven't done your homework
because I'm always right."- "Strict typing would break everything! What? You're not talking
about C-like strict typing? Sorry, I didn't catch that. Strict typing
would break everything!...."- "I don't care if you've already countered my argument. I'll just
keep repeating myself as if you didn't."Variations of the above statements have been posted ad nauseum. They're
all based on logical fallacies and are not constructive.I'm putting this out there: If anyone posts one or more of the above
arguments yet again on this topic, I will personally extract one of your
kidneys and sell it to a questionable "dog food" company in Shanghai. I
will then openly mock your intellectual laziness and encourage people to
ignore you. ;PI'd love to prove Daniel wrong, but I think he may be on to
something.... :\it is weird that you are calling others rude.
I'm sure you would feel hurt/personally attacked, if somebody would create
a similar list of the little bit twisted arguments of yours.
could we stay on the topic?
another 14 mails to read. :/--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Discussed to death. Yet only one time before (discussing a specific
patch)...
Did you go back to the old, old, old PHP list (and was it PHP-dev back
then?), before it split into php-general and php-internals and php-*,
back when there weren't enough users to warrant more than two lists?
You may find more fruitful results there, I think.
Or not.
Did you check the wiki and RFCs that came out of those discussions?
Those are the places where the really serious proposals with patches
developed after the mailing list wrangling.
They all failed, in the end, but those are the ones that actually got
taken seriously, because they had enough specificity to discuss for or
against for technical merit.
The idea has always always had some technical merit. The
implementation, however, has always failed.
The very strict typing usually failed quickly.
The not so strict typing either failed after a lot of effort, and edge
cases kept cropping up, or ended up being so weak as to not provide
any additional value over the original dynamic typing.
The patches are out there. The conclusions and technical issues are
out there. They may be lost in the sea of flame-wars, but they do
exist.
If you don't like this feature, and you can explain from a TECHNICAL
perspective why, please do so! If you don't like the feature, and are
going to lean on "It's not Java", or "We've discussed this to death
already", please don't...
Stas has already stated that you can't do what you want and have it
mean anything without changing the very nature of PHP.
I said the same, poorly, and invite you to TRY with a patch instead of
discussing it endlessly here.
And to be fair: "and you can provide new arguments to the discussion"
has already happened quite a bit (dating back the past 5 years), but
those arguments were ignored or overruled for political reasons.
Write the proof of concept patch, please.
Then we can discuss the technical merits or prove why it won't work.
Otherwise, it really is an endless discussion of a dead horse.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
Ok, fine. We get it. You don't think this can be done. Duly noted.
Now that you've voiced your opposition, can we please dedicate this topic
to discussing how this can be done? If you think we're wasting our time,
then ok; it's our time to waste. I'd be happy to take you up on your
challenge to try to implement this, but first we have to brainstorm what
exactly we'll be doing. And that'll be much easier if we don't have to
keep sifting through duplicate posts about why this is a bad idea. Let's
just set that aside for now so we can brainstorm.
On that note, I would like to direct everyone's attention to my last post
where I suggested a new "strong" concept.
--Kris
Discussed to death. Yet only one time before (discussing a specific
patch)...Did you go back to the old, old, old PHP list (and was it PHP-dev back
then?), before it split into php-general and php-internals and php-*,
back when there weren't enough users to warrant more than two lists?You may find more fruitful results there, I think.
Or not.
Did you check the wiki and RFCs that came out of those discussions?
Those are the places where the really serious proposals with patches
developed after the mailing list wrangling.They all failed, in the end, but those are the ones that actually got
taken seriously, because they had enough specificity to discuss for or
against for technical merit.The idea has always always had some technical merit. The
implementation, however, has always failed.The very strict typing usually failed quickly.
The not so strict typing either failed after a lot of effort, and edge
cases kept cropping up, or ended up being so weak as to not provide
any additional value over the original dynamic typing.The patches are out there. The conclusions and technical issues are
out there. They may be lost in the sea of flame-wars, but they do
exist.If you don't like this feature, and you can explain from a TECHNICAL
perspective why, please do so! If you don't like the feature, and are
going to lean on "It's not Java", or "We've discussed this to death
already", please don't...Stas has already stated that you can't do what you want and have it
mean anything without changing the very nature of PHP.I said the same, poorly, and invite you to TRY with a patch instead of
discussing it endlessly here.And to be fair: "and you can provide new arguments to the discussion"
has already happened quite a bit (dating back the past 5 years), but
those arguments were ignored or overruled for political reasons.Write the proof of concept patch, please.
Then we can discuss the technical merits or prove why it won't work.
Otherwise, it really is an endless discussion of a dead horse.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
Now that you've voiced your opposition, can we please dedicate this
topic
to discussing how this can be done? If you think we're wasting our
time,
then ok; it's our time to waste. I'd be happy to take you up on your
challenge to try to implement this, but first we have to brainstorm
what
exactly we'll be doing. And that'll be much easier if we don't have
to
keep sifting through duplicate posts about why this is a bad idea.
Let's
just set that aside for now so we can brainstorm.
Last post on this topic:
Would you please consider creating a separate list or wiki page or
incomplete RFC, so that those of us who consider the discussion
fruitless from past experience can ignore it until it crystallizes a
bit more?
A weekly update to the list, or even daily, of the progress would be
quite reasonable, and keep everybody in the loop, without the details
and less "flames".
I truly believe this will be a more constructive use of your time, and
ours, or I would not ask it of you.
Thanks!
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
On Mon, Feb 27, 2012 at 6:38 PM, Anthony Ferrara ircmaxell@gmail.comwrote:
no, it is: "come back after you did your homework, and you can provide
new
arguments to the discussion"To be completely fair, I did homework on this. I went back to 2000 on
marc.info's archives and read almost all of the 400 posts matching the
search http://marc.info/?l=php-internals&w=2&r=13&s=strict+typing&q=b
and a bunch of the posts on
http://marc.info/?l=php-internals&w=2&r=54&s=type+hinting&q=b
that's nice.
as I mentioned in my previous (and maybe in some other) mail, I think that
it would be really nice to have those discussions summarized.
sorry for replying your mail later than some others, but I was afraid of
the wall of text. :)
The vast majority of what I found were quite good arguments for
including the feature. I found quite a bit of "this was discussed to
death, do your homework and provide new arguments". What's odd, is
that one of the earliest on-topic threads that I found (2007:
http://marc.info/?l=php-internals&m=119514660125258&w=2 ) had this as
the third reply. The only on-topic discussion that I found prior to
that was in 2006 (almost exactly 1 year prior:
http://marc.info/?l=php-internals&m=116257685415135&w=2 ).Discussed to death. Yet only one time before (discussing a specific
patch)...
I only joined the lists like 3 years ago, but I remember discussing this
idea more than that.
I can dig up the threads if you are interested, the biggest discussion was
after Derick commited the scalar typehint patch from Ilia to trunk and
after a pretty heated and long discussion and multiple alternative
proposals the patch was reverted and Derick implemented a Reflection based
infrastructure for checking the typehints.
some history:
2006
http://derickrethans.nl/typehints-for-scalar-types.html
http://php.markmail.org/message/nalhrp5n5p3srj7u#query:+page:1+mid:nalhrp5n5p3srj7u+state:results
2008
https://wiki.php.net/rfc/typehint
2009
http://ilia.ws/archives/205-Type-hinting-for-PHP-5.3.html
http://schlitt.info/opensource/blog/0712_scalar_type_hints_in_php.html
2010
http://ilia.ws/archives/217-Scalar-Type-Hints-are-Here!.html
http://schlueters.de/blog/archives/139-Scalar-type-hints-in-PHP-trunk.html
http://schlueters.de/blog/archives/148-More-on-scalar-type-hints-in-PHP-trunk.html
And the opponents still said no...
with the new RFC process there is a rule of thumb/gentlemen agreement that
if a large portion of the core devs are against a specific change, then it
shouldn't be added, or to form it otherwise consensus should be reached
instead of pushing through changes by 50%+1 (or 66%+1).
this specific change was such a controversial one that we couldn't reach
conclusion..
There were also quite a few problems identified with scalar hinting
and auto-casting vs strict erroring. However, there were also
solutions proposed to nearly each and every one of them.
There were ideas, but they didn't have enough traction.
IMO we can't have a proper solution without changing the existing behavior
for complex types, if you implement strict typing for scalars that turns
the language strict typed, if you add dynamic/weak typing for the scalars,
you will have an inconsistent implementation.
And the opponents still said no...
to tell the truth they said no, but it was the original commiter who
reverted the change.
(sorry Derick, I don't remember the details, feel free to correct me on
this.)
It has been brought up time and time again. Solutions have been
proposed which have no fundimental issues (inconsistencies,
problematic operations - such as references, etc)...
maybe I missed those, what are you referring to?
I see the ones that I linked + the following:
https://wiki.php.net/rfc/typechecking
https://wiki.php.net/rfc/autoboxing
https://wiki.php.net/rfc/boxingandunboxing
https://wiki.php.net/rfc/splweaktypehintingwithautoboxing
And the opponents instead said "this has been discussed to death, no"...
nope, they first discussed to death. then when people without much insight
or knowledge without the past discussion brought back the topic, some
people felt that it is too soon to discuss it again, as nothing new is on
the table.
Please can you stop saying "this has been discussed to death". To be
frank, don't stop the discussion because you don't like the idea. It
has been discussed to death. But the discussion has only really ever
involved people who are for it. The opponents by and large have used
two arguments: "It has been discussed already, so no" and "don't make
PHP into Java".
I don't mind what others do with their free time, so feel free to discuss
it, but somehow it seems for that some people are wasting their time
running the same circles others did years before, and yelling others for
not reading through 50 mails (from which maybe 5-10 has insightful
comments) or wanting to discuss the topic in detail.
I really think that after seeing this as a hot topic as it is, that we
don't have a proper wiki page summarizing and linking all of the previous
discussions. That way even if we can't find the final/best solution, we
could continue the discussion anytime, and we could just point
the newcomers to that page, and they would be able to catch up.
I really think that it is no bad intention from the php devs side in this
topic, but they are burned out discussing this, and the general tone and
finger pointing of this thread doesn't really help the issue.
If somebody have the time, and would like to move this forward, the first
step would be to trying to understand the issue and hand, gathering all
previous discussion/info available, creating a wiki page then:
- document what is the current typehinting implementation, what are the
pro/cons. - what are the pros/cons for scalar type hints in general.
- what are the pros/cons for weak/strict scalar type hints in general
- what are the previously suggested solutions/implementations, what are the
pros/cons for them - (optionally do the same for the return type hints)
There has been some discussion of technical merit and problem
resolution by opponents, but finding it is VERY difficult among all
the down trodding commentary.
I found your usage of the word opponent a little bit disturbing, but maybe
I'm just thinking into it too much.
I agree that it is frustrating if your arguments are turned down that "we
already discussed that" (been there, done that. I mean in your situation).
I also think that it would also help if the signal/noise(+personal attack)
ration would be better. Usually I try to follow the discussion on the list,
but I have to tell you that I'm almost out of being able to do that, as the
discussion seems to have lack of focus (Scalar type hinting, Object
Casting, both spawned from the ENUM proposal and there are also 3-4 other
hot topics currently.).
I think that we all should calm down a little bit, and catch up with the
reading and focus on how to solve the issue instead of just trying to prove
that the "opponent" is wrong.
So let me make a plea:
If you don't like this feature, and you can explain from a TECHNICAL
perspective why, please do so! If you don't like the feature, and are
going to lean on "It's not Java", or "We've discussed this to death
already", please don't...
This goes both way, so one side would need to not turn down the other
simply based on the past discussion, but the other side should also read
those discussions if provided.
I think that I expressed my personal opinion and linked a few articles and
I can also gather some of the discussions on the mailing list (at least
what took place after me joining the list).
Now it would be nice if you could point out that what are your solutions
those technical arguments brought up there.
And to be fair: "and you can provide new arguments to the discussion"
has already happened quite a bit (dating back the past 5 years), but
those arguments were ignored or overruled for political reasons.
I disagree.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Ferenc,
Thanks for the comments!
On Mon, Feb 27, 2012 at 6:38 PM, Anthony Ferrara ircmaxell@gmail.com
wrote:no, it is: "come back after you did your homework, and you can provide
new
arguments to the discussion"To be completely fair, I did homework on this. I went back to 2000 on
marc.info's archives and read almost all of the 400 posts matching the
search http://marc.info/?l=php-internals&w=2&r=13&s=strict+typing&q=b
and a bunch of the posts on
http://marc.info/?l=php-internals&w=2&r=54&s=type+hinting&q=bthat's nice.
as I mentioned in my previous (and maybe in some other) mail, I think that
it would be really nice to have those discussions summarized.
sorry for replying your mail later than some others, but I was afraid of the
wall of text. :)
Without committing to anything, I will try to find time to do so...
The vast majority of what I found were quite good arguments for
including the feature. I found quite a bit of "this was discussed to
death, do your homework and provide new arguments". What's odd, is
that one of the earliest on-topic threads that I found (2007:
http://marc.info/?l=php-internals&m=119514660125258&w=2 ) had this as
the third reply. The only on-topic discussion that I found prior to
that was in 2006 (almost exactly 1 year prior:
http://marc.info/?l=php-internals&m=116257685415135&w=2 ).Discussed to death. Yet only one time before (discussing a specific
patch)...I only joined the lists like 3 years ago, but I remember discussing this
idea more than that.
I can dig up the threads if you are interested, the biggest discussion was
after Derick commited the scalar typehint patch from Ilia to trunk and after
a pretty heated and long discussion and multiple alternative proposals the
patch was reverted and Derick implemented a Reflection based infrastructure
for checking the typehints.
Well, that's absolutely relevant, but that was for one of the
possibilities on how to implement it. But worth bringing up...
some history:
2006
http://derickrethans.nl/typehints-for-scalar-types.html
http://php.markmail.org/message/nalhrp5n5p3srj7u#query:+page:1+mid:nalhrp5n5p3srj7u+state:results
2008
https://wiki.php.net/rfc/typehint
2009
http://ilia.ws/archives/205-Type-hinting-for-PHP-5.3.html
http://schlitt.info/opensource/blog/0712_scalar_type_hints_in_php.html
2010
http://ilia.ws/archives/217-Scalar-Type-Hints-are-Here!.html
http://schlueters.de/blog/archives/139-Scalar-type-hints-in-PHP-trunk.html
http://schlueters.de/blog/archives/148-More-on-scalar-type-hints-in-PHP-trunk.html
That's quite helpful.
And the opponents still said no...
with the new RFC process there is a rule of thumb/gentlemen agreement that
if a large portion of the core devs are against a specific change, then it
shouldn't be added, or to form it otherwise consensus should be reached
instead of pushing through changes by 50%+1 (or 66%+1).
this specific change was such a controversial one that we couldn't reach
conclusion..
I have no problem with the maintainers/core devs saying no if they
really feel it's bad (in fact, I agree with it). What I do have a
problem with is them (or anyone) saying no without understanding what
they are saying no to (which is obvious by some of the comments, and
by some of the banter about "PHP is not java").
There were also quite a few problems identified with scalar hinting
and auto-casting vs strict erroring. However, there were also
solutions proposed to nearly each and every one of them.There were ideas, but they didn't have enough traction.
IMO we can't have a proper solution without changing the existing behavior
for complex types, if you implement strict typing for scalars that turns the
language strict typed, if you add dynamic/weak typing for the scalars, you
will have an inconsistent implementation.
What behavior would need to be changed for complex types? Adding the
ability to hint/cast between trees? I'm kind of confused by this
bit...
And the opponents still said no...
to tell the truth they said no, but it was the original commiter who
reverted the change.
(sorry Derick, I don't remember the details, feel free to correct me on
this.)
Sure, but again, that's talking about implementing very strict typing
(fatal on incorrect). Which to be perfectly honest, I would say no to
as well. But I think there's enough merit to continue the discussion,
and separate the concepts... But very fair point...
It has been brought up time and time again. Solutions have been
proposed which have no fundimental issues (inconsistencies,
problematic operations - such as references, etc)...maybe I missed those, what are you referring to?
I see the ones that I linked + the following:
https://wiki.php.net/rfc/typecheckinghttps://wiki.php.net/rfc/autoboxing
https://wiki.php.net/rfc/boxingandunboxing
https://wiki.php.net/rfc/splweaktypehintingwithautoboxing
I'm talking about in the lists, message by message. Perhaps most of
them didn't actually get into RFC, or were glossed over, or lost in
the noise...
And the opponents instead said "this has been discussed to death, no"...
nope, they first discussed to death. then when people without much insight
or knowledge without the past discussion brought back the topic, some people
felt that it is too soon to discuss it again, as nothing new is on the
table.
I understand that sentiment. I really do. But at the same token, why
do we need to kill the conversations from happening? Why not ignore
it if you think it's too soon, and let the others get to the point of
an RFC with patch, and then step in and see how the idea matured.
I think that's my biggest problem with the dynamics of this list.
Ideas aren't really nurtured as well as they could be. If the idea is
solid, and has an implementation, then it's great. But there are
plenty of seedling ideas that get lost or down trodden-ed simply
because it's not bulletproof...
Please can you stop saying "this has been discussed to death". To be
frank, don't stop the discussion because you don't like the idea. It
has been discussed to death. But the discussion has only really ever
involved people who are for it. The opponents by and large have used
two arguments: "It has been discussed already, so no" and "don't make
PHP into Java".I don't mind what others do with their free time, so feel free to discuss
it, but somehow it seems for that some people are wasting their time running
the same circles others did years before, and yelling others for not reading
through 50 mails (from which maybe 5-10 has insightful comments) or wanting
to discuss the topic in detail.
I really think that after seeing this as a hot topic as it is, that we don't
have a proper wiki page summarizing and linking all of the previous
discussions. That way even if we can't find the final/best solution, we
could continue the discussion anytime, and we could just point
the newcomers to that page, and they would be able to catch up.
I really think that it is no bad intention from the php devs side in this
topic, but they are burned out discussing this, and the general tone and
finger pointing of this thread doesn't really help the issue.
If somebody have the time, and would like to move this forward, the first
step would be to trying to understand the issue and hand, gathering all
previous discussion/info available, creating a wiki page then:
- document what is the current typehinting implementation, what are the
pro/cons.- what are the pros/cons for scalar type hints in general.
- what are the pros/cons for weak/strict scalar type hints in general
- what are the previously suggested solutions/implementations, what are the
pros/cons for them- (optionally do the same for the return type hints)
I think that was the point of this very thread, if I'm not mistaken...
There has been some discussion of technical merit and problem
resolution by opponents, but finding it is VERY difficult among all
the down trodding commentary.I found your usage of the word opponent a little bit disturbing, but maybe
I'm just thinking into it too much.
Well, I mean it as it comes off, to an extent. I mean the very small
group of people who are littered in these threads who are saying "PHP
is not Java" and shooting down the idea without even considering it
(in the least). If you don't think it can be done, that's a different
story. I'm talking about the people who have nothing constructive at
all to add, yet generate these long diatribes of dialog, without
getting anything done...
I agree that it is frustrating if your arguments are turned down that "we
already discussed that" (been there, done that. I mean in your situation).
I also think that it would also help if the signal/noise(+personal attack)
ration would be better. Usually I try to follow the discussion on the list,
but I have to tell you that I'm almost out of being able to do that, as the
discussion seems to have lack of focus (Scalar type hinting, Object Casting,
both spawned from the ENUM proposal and there are also 3-4 other hot topics
currently.).
I think that we all should calm down a little bit, and catch up with the
reading and focus on how to solve the issue instead of just trying to prove
that the "opponent" is wrong.
Sounds good to me!
So let me make a plea:
If you don't like this feature, and you can explain from a TECHNICAL
perspective why, please do so! If you don't like the feature, and are
going to lean on "It's not Java", or "We've discussed this to death
already", please don't...This goes both way, so one side would need to not turn down the other simply
based on the past discussion, but the other side should also read those
discussions if provided.
I think that's the problem. I don't mind "It has been discussed
before, here and here, can you solve those problems". If links are
provided, I think it's 100% reasonable to have people read the links
that were provided. I don't consider it reasonable to ask people to
"go read prior discussions" without any insight onto which (and which
are even valid anymore due to engine changes, and the like). That's
like telling someone to just go google it. Sure, but if you don't
know what you're looking for, a huge time waster (and a bit
disrespectful as well)...
I think that I expressed my personal opinion and linked a few articles and I
can also gather some of the discussions on the mailing list (at least what
took place after me joining the list).
Now it would be nice if you could point out that what are your solutions
those technical arguments brought up there.
I'll go through them tonight when I get some free time.
Thanks a bunch,
Anthony
And to be fair: "and you can provide new arguments to the discussion"
has already happened quite a bit (dating back the past 5 years), but
those arguments were ignored or overruled for political reasons.I disagree.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Ferenc,
Thanks for the comments!
Thanks from me, too.
And thanks to you, Anthony if you get to summarise that.
There were ideas, but they didn't have enough traction.
IMO we can't have a proper solution without changing the existing behavior
for complex types, if you implement strict typing for scalars that turns the
language strict typed, if you add dynamic/weak typing for the scalars, you
will have an inconsistent implementation.
What behavior would need to be changed for complex types? Adding the
ability to hint/cast between trees? I'm kind of confused by this
bit...
I suspect one of the scalars should be complex (= objects?)
I think that's my biggest problem with the dynamics of this list.
Ideas aren't really nurtured as well as they could be. If the idea is
solid, and has an implementation, then it's great. But there are
plenty of seedling ideas that get lost or down trodden-ed simply
because it's not bulletproof...
Yes, the noise ratio of this list is quite high. Probably related to its
high
volume. That makes people faster in discarding ideas as "been there"
and generates friction. And low-quality discussions like that don't
attract smart people insights, precisely.
It's a vicious circle.
I agree. What does everyone think about the idea of creating a new list
specifically discussion of new feature ideas? The idea could be announced
on the Internals list with a link to the discussion on the other list.
That way, the noise ratio would be reduced and only those who are
interested in brainstorming new ideas would have to listen to it.
Thoughts?
--Kris
2012/2/27 Ángel González keisial@gmail.com
Ferenc,
Thanks for the comments!
Thanks from me, too.And thanks to you, Anthony if you get to summarise that.
There were ideas, but they didn't have enough traction.
IMO we can't have a proper solution without changing the existing
behavior
for complex types, if you implement strict typing for scalars that
turns the
language strict typed, if you add dynamic/weak typing for the scalars,
you
will have an inconsistent implementation.
What behavior would need to be changed for complex types? Adding the
ability to hint/cast between trees? I'm kind of confused by this
bit...
I suspect one of the scalars should be complex (= objects?)I think that's my biggest problem with the dynamics of this list.
Ideas aren't really nurtured as well as they could be. If the idea is
solid, and has an implementation, then it's great. But there are
plenty of seedling ideas that get lost or down trodden-ed simply
because it's not bulletproof...
Yes, the noise ratio of this list is quite high. Probably related to its
high
volume. That makes people faster in discarding ideas as "been there"
and generates friction. And low-quality discussions like that don't
attract smart people insights, precisely.
It's a vicious circle.
I don't think we need yet another list. That said, I think that some features (such as weak typing) would benefit greatly from having a small body of people get together and flesh out a proposal together before presenting it for sacrifice on the altar of public discussion. Part of the value in this is keeping the group limited to just collaborators on that specific feature, so a general features mailing list wouldn't really add anything.
Not sure how you want to coordinate this group. In my company we have a distributed team and we typically coordinate this sort of design process using Google Docs + Donedesk(our own product, but free) + Skype. This works well and strikes a nice balance between persistent and realtime collaboration. I'm open to other ideas, but if I had to choose how to coordinate a group to design a single feature, that's what I would use.
John Crenshaw
Priacta, Inc.
-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Monday, February 27, 2012 6:36 PM
To: Ángel González
Cc: Anthony Ferrara; Ferenc Kovacs; Michael Morris; internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hinting
I agree. What does everyone think about the idea of creating a new list specifically discussion of new feature ideas? The idea could be announced on the Internals list with a link to the discussion on the other list.
That way, the noise ratio would be reduced and only those who are interested in brainstorming new ideas would have to listen to it.
Thoughts?
--Kris
2012/2/27 Ángel González keisial@gmail.com
Ferenc,
Thanks for the comments!
Thanks from me, too.And thanks to you, Anthony if you get to summarise that.
There were ideas, but they didn't have enough traction.
IMO we can't have a proper solution without changing the existing
behavior
for complex types, if you implement strict typing for scalars that
turns the
language strict typed, if you add dynamic/weak typing for the
scalars,
you
will have an inconsistent implementation.
What behavior would need to be changed for complex types? Adding
the ability to hint/cast between trees? I'm kind of confused by
this bit...
I suspect one of the scalars should be complex (= objects?)I think that's my biggest problem with the dynamics of this list.
Ideas aren't really nurtured as well as they could be. If the idea
is solid, and has an implementation, then it's great. But there are
plenty of seedling ideas that get lost or down trodden-ed simply
because it's not bulletproof...
Yes, the noise ratio of this list is quite high. Probably related to
its high volume. That makes people faster in discarding ideas as "been
there"
and generates friction. And low-quality discussions like that don't
attract smart people insights, precisely.
It's a vicious circle.--
To unsubscribe,
visit: http://www.php.net/unsub.php
Lol you're making me feel like an old fogey! I've always just used
email/listservs (or carrier pigeon if I'm getting a busy signal dialing in
to AOL).
Either way, I think we should give serious thought to how we move forward
on this, as it could wind up being a blueprint for future PHP feature
collaborations. I do agree with all your points though. Let me ponder
over it a little bit then get back to ya, just in case I have a better idea
that I haven't thought of yet. ;)
--Kris
2012/2/27 John Crenshaw johncrenshaw@priacta.com
I don't think we need yet another list. That said, I think that some
features (such as weak typing) would benefit greatly from having a small
body of people get together and flesh out a proposal together before
presenting it for sacrifice on the altar of public discussion. Part of the
value in this is keeping the group limited to just collaborators on that
specific feature, so a general features mailing list wouldn't really add
anything.Not sure how you want to coordinate this group. In my company we have a
distributed team and we typically coordinate this sort of design process
using Google Docs + Donedesk(our own product, but free) + Skype. This works
well and strikes a nice balance between persistent and realtime
collaboration. I'm open to other ideas, but if I had to choose how to
coordinate a group to design a single feature, that's what I would use.John Crenshaw
Priacta, Inc.-----Original Message-----
From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Monday, February 27, 2012 6:36 PM
To: Ángel González
Cc: Anthony Ferrara; Ferenc Kovacs; Michael Morris;
internals@lists.php.net
Subject: Re: [PHP-DEV] Scalar type hintingI agree. What does everyone think about the idea of creating a new list
specifically discussion of new feature ideas? The idea could be announced
on the Internals list with a link to the discussion on the other list.
That way, the noise ratio would be reduced and only those who are
interested in brainstorming new ideas would have to listen to it.Thoughts?
--Kris
2012/2/27 Ángel González keisial@gmail.com
Ferenc,
Thanks for the comments!
Thanks from me, too.And thanks to you, Anthony if you get to summarise that.
There were ideas, but they didn't have enough traction.
IMO we can't have a proper solution without changing the existing
behavior
for complex types, if you implement strict typing for scalars that
turns the
language strict typed, if you add dynamic/weak typing for the
scalars,
you
will have an inconsistent implementation.
What behavior would need to be changed for complex types? Adding
the ability to hint/cast between trees? I'm kind of confused by
this bit...
I suspect one of the scalars should be complex (= objects?)I think that's my biggest problem with the dynamics of this list.
Ideas aren't really nurtured as well as they could be. If the idea
is solid, and has an implementation, then it's great. But there are
plenty of seedling ideas that get lost or down trodden-ed simply
because it's not bulletproof...
Yes, the noise ratio of this list is quite high. Probably related to
its high volume. That makes people faster in discarding ideas as "been
there"
and generates friction. And low-quality discussions like that don't
attract smart people insights, precisely.
It's a vicious circle.--
To unsubscribe,
visit: http://www.php.net/unsub.php
Aren't you people getting tired of saying that arguments like "it's
not the PHP way" or "that does not fit the PHP paradigm" are invalid.
Are you even aware, that language is not only about the features, but
is also about the paradigm, syntax, philosophy and methods of how it
achieves it's goals? It's not as simple as "nah, lets add feature X,
it looks weird and alien, but who cares as long as it's cool!".
On the terminology - strict is strict, weak is weak. Writing a
statement at the start of the thread and adding a few new words will
make no difference. Because half the people will just skip it, or
didn't read carefully because it's not interesting and so on. Some
people on the list just assume that we are perfect beings and read
every line of what's written on the list (hell, I skim the text and
read only the important things. I have ~15 threads active in my
mailbox (only the internals, not counting other mail) and reading each
of it carefully will just take too long).
Besides that - a scripting language is much easier to learn, use it
and learn it. Things like strict typing, strict type hinting and so on
are not as trivial to understand and learn unless you start with a
strict typed compiled language. When you deal with the script language
and loose variable typing you get used to being able to convert types
on the fly. And imagine the shock when you start using some strict
typed library and now you have to convert all your variables
explicitly. And now the code looks just like C/C++/Java/Delphi code -
type conversion statements all over the place. I sure don't want such
code. And not because it is hard to combine (or impossible) weak and
strict type hinting - that just does not suit a scripting language
created with loose/weak typing in the first place. And adding such
things will not improve the code - it will mess it up big time. I
don't know about you, but I have seen and worked with folks who did
some really weird things in PHP. An instrument like strict type
hinting will just give them the ability to write code that is plain
stupid. It will be just like OOP for the sake of OOP. Too many people
do not understand the philosophy behind the PHP and they build over
complex things and complain that they had to become "inventive" to be
able to do implement something from the C++/Java/Python/Ruby world.
And they complain that PHP is a bad language, but still eat the
cactus. I wonder why?
I really liked what the O'Raily wrote here:
http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html
I know, some things are a little over the top, but in general it
describes the best PHP feature - it's easy to work with, it's easy to
make something without using any frameworks, libraries and just do the
work you need for the WEB.
And I think it should stay that way. And I personally like it that
way. And it's because of that I don't want to migrate to Ryby or
Python. Adding strict type hinting will ruin it because I know for a
fact that there are plenty of programmers who will turn their API's
into strict typed all over the place. And I will have to select my
data from the database and go through the records and explicitly
convert all my data to the correct types so I can use that wonderful
library whose author is a fond of strict typing. I see such things
with OOP right now in many places - they ask you for an object, but I
know it just really needs a string with the data to do the work.
Many people migrate to PHP from different languages, and mostly those
are strictly typed compile languages (I actually had teached PHP for 2
years at the private school of web technologies - I saw many people
learning PHP after Java, C++, Delphi, even assembler).
It's not the problem that will become a problem in a year or two - it
will become so in 5-7 years. Just like register_globals, magic_quotes
and things like that gave their evil effects in time.
So please, take your time to think this through. The technical aspect
is only part of the puzzle. As they say "The road to hell is paved
with good intentions". And adding strict and weak type hinting
together is just plainly a very bad idea. It may be good for library
and framework writers (but not all of them agree on that), but to the
people using them it will be a headache.
Hello everyone,
Let's stop the religious war between strongly and weekly typed languages.
In software, there is no silver bullet. Both approaches have their benefits
and their disadvantages, so trying to prove that one is better to the other
leads to nowhere.
Having said that, I don't think that PHP will any time soon become a
strongly typed language. However, as there are indeed benefits to strongly
typed languages, I see no reason to just close the door. I think it's high
time that we separated the PHP platform from the PHP language. That
will eventually lead to the creation of strongly typed languages that could
be executed on the PHP platform.
Just my two cents :-)
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/2/28 Arvids Godjuks arvids.godjuks@gmail.com
Aren't you people getting tired of saying that arguments like "it's
not the PHP way" or "that does not fit the PHP paradigm" are invalid.
Are you even aware, that language is not only about the features, but
is also about the paradigm, syntax, philosophy and methods of how it
achieves it's goals? It's not as simple as "nah, lets add feature X,
it looks weird and alien, but who cares as long as it's cool!".
On the terminology - strict is strict, weak is weak. Writing a
statement at the start of the thread and adding a few new words will
make no difference. Because half the people will just skip it, or
didn't read carefully because it's not interesting and so on. Some
people on the list just assume that we are perfect beings and read
every line of what's written on the list (hell, I skim the text and
read only the important things. I have ~15 threads active in my
mailbox (only the internals, not counting other mail) and reading each
of it carefully will just take too long).Besides that - a scripting language is much easier to learn, use it
and learn it. Things like strict typing, strict type hinting and so on
are not as trivial to understand and learn unless you start with a
strict typed compiled language. When you deal with the script language
and loose variable typing you get used to being able to convert types
on the fly. And imagine the shock when you start using some strict
typed library and now you have to convert all your variables
explicitly. And now the code looks just like C/C++/Java/Delphi code -
type conversion statements all over the place. I sure don't want such
code. And not because it is hard to combine (or impossible) weak and
strict type hinting - that just does not suit a scripting language
created with loose/weak typing in the first place. And adding such
things will not improve the code - it will mess it up big time. I
don't know about you, but I have seen and worked with folks who did
some really weird things in PHP. An instrument like strict type
hinting will just give them the ability to write code that is plain
stupid. It will be just like OOP for the sake of OOP. Too many people
do not understand the philosophy behind the PHP and they build over
complex things and complain that they had to become "inventive" to be
able to do implement something from the C++/Java/Python/Ruby world.
And they complain that PHP is a bad language, but still eat the
cactus. I wonder why?I really liked what the O'Raily wrote here:
http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html
I know, some things are a little over the top, but in general it
describes the best PHP feature - it's easy to work with, it's easy to
make something without using any frameworks, libraries and just do the
work you need for the WEB.
And I think it should stay that way. And I personally like it that
way. And it's because of that I don't want to migrate to Ryby or
Python. Adding strict type hinting will ruin it because I know for a
fact that there are plenty of programmers who will turn their API's
into strict typed all over the place. And I will have to select my
data from the database and go through the records and explicitly
convert all my data to the correct types so I can use that wonderful
library whose author is a fond of strict typing. I see such things
with OOP right now in many places - they ask you for an object, but I
know it just really needs a string with the data to do the work.
Many people migrate to PHP from different languages, and mostly those
are strictly typed compile languages (I actually had teached PHP for 2
years at the private school of web technologies - I saw many people
learning PHP after Java, C++, Delphi, even assembler).
It's not the problem that will become a problem in a year or two - it
will become so in 5-7 years. Just like register_globals, magic_quotes
and things like that gave their evil effects in time.So please, take your time to think this through. The technical aspect
is only part of the puzzle. As they say "The road to hell is paved
with good intentions". And adding strict and weak type hinting
together is just plainly a very bad idea. It may be good for library
and framework writers (but not all of them agree on that), but to the
people using them it will be a headache.
I don't want it to be a strongly typed language. Whatever you call it
(weakly typed, loosely typed), I want a change to where the option
to declare a datatype exists. I do not want it to be required, both
for backwards compatibility and also for barrier to entry reasons.
In my mind given: (this is one continuous example)
$a = 123;
And given the function
function foo ( int $i ) {}
Then if we call
foo($a);
We are ok. If we call
foo("123")
We are still ok, since the conversion of "123" to 123 is non-lossy. We
get a notice though, because unlike $a, which is a scalar, "123" is an
explicit string value.
$a = "456";
foo($a);
We are ok, and no notice is raised. $a is a scalar. It is the
datatype it needs to be to fulfill the request.
int $a = 123;
A is now type locked to integer. So
$a = "456";
will raise an E_Notice and so will
$a = "Hello World";
If we want $a to go back to being a scalar one might try...
unset($a);
$a = "Hello World";
And yes, $a is starting all over here because of the unset.
int $a;
$a had a value which can't convert without loss of data, E_NOTICE.
scalar $a;
And if we don't want to unset $a but rather restore $a to behaving
like a scalar, that is how it would be done. We can of course
formally declare scalars at all times, and I imagine some programmers
will do this for self documenting code reasons, but the scalar keyword
would only be needed if an existing variable needed it's type
unlocked. Meanwhile, remember that foo function above.
$a = "456"
foo($a);
As proposed, works, no error as discussed above.
$a = "Hello World";
foo($a);
E_NOTICE raised.
string $a;
foo($a);
E_WARNING raised. The reason for this higher error state to be raised
is an attempt was made to place an explicit string into an explicit
integer. That shouldn't occur. Code proceeds by doing the conversion.
So, in closing this ramble, if I right a db library whose functions
are datatyped you might see more notices, but the code will work and
notices are usually suppressed by default (yes, I know about the RFC
to change that)
Hello everyone,
Let's stop the religious war between strongly and weekly typed languages.
In software, there is no silver bullet. Both approaches have their benefits
and their disadvantages, so trying to prove that one is better to the other
leads to nowhere.Having said that, I don't think that PHP will any time soon become a
strongly typed language. However, as there are indeed benefits to strongly
typed languages, I see no reason to just close the door. I think it's high
time that we separated the PHP platform from the PHP language. That
will eventually lead to the creation of strongly typed languages that could
be executed on the PHP platform.Just my two cents :-)
Lazare INEPOLOGLOU
Ingénieur Logiciel2012/2/28 Arvids Godjuks arvids.godjuks@gmail.com
Aren't you people getting tired of saying that arguments like "it's
not the PHP way" or "that does not fit the PHP paradigm" are invalid.
Are you even aware, that language is not only about the features, but
is also about the paradigm, syntax, philosophy and methods of how it
achieves it's goals? It's not as simple as "nah, lets add feature X,
it looks weird and alien, but who cares as long as it's cool!".
On the terminology - strict is strict, weak is weak. Writing a
statement at the start of the thread and adding a few new words will
make no difference. Because half the people will just skip it, or
didn't read carefully because it's not interesting and so on. Some
people on the list just assume that we are perfect beings and read
every line of what's written on the list (hell, I skim the text and
read only the important things. I have ~15 threads active in my
mailbox (only the internals, not counting other mail) and reading each
of it carefully will just take too long).Besides that - a scripting language is much easier to learn, use it
and learn it. Things like strict typing, strict type hinting and so on
are not as trivial to understand and learn unless you start with a
strict typed compiled language. When you deal with the script language
and loose variable typing you get used to being able to convert types
on the fly. And imagine the shock when you start using some strict
typed library and now you have to convert all your variables
explicitly. And now the code looks just like C/C++/Java/Delphi code -
type conversion statements all over the place. I sure don't want such
code. And not because it is hard to combine (or impossible) weak and
strict type hinting - that just does not suit a scripting language
created with loose/weak typing in the first place. And adding such
things will not improve the code - it will mess it up big time. I
don't know about you, but I have seen and worked with folks who did
some really weird things in PHP. An instrument like strict type
hinting will just give them the ability to write code that is plain
stupid. It will be just like OOP for the sake of OOP. Too many people
do not understand the philosophy behind the PHP and they build over
complex things and complain that they had to become "inventive" to be
able to do implement something from the C++/Java/Python/Ruby world.
And they complain that PHP is a bad language, but still eat the
cactus. I wonder why?I really liked what the O'Raily wrote here:
http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html
I know, some things are a little over the top, but in general it
describes the best PHP feature - it's easy to work with, it's easy to
make something without using any frameworks, libraries and just do the
work you need for the WEB.
And I think it should stay that way. And I personally like it that
way. And it's because of that I don't want to migrate to Ryby or
Python. Adding strict type hinting will ruin it because I know for a
fact that there are plenty of programmers who will turn their API's
into strict typed all over the place. And I will have to select my
data from the database and go through the records and explicitly
convert all my data to the correct types so I can use that wonderful
library whose author is a fond of strict typing. I see such things
with OOP right now in many places - they ask you for an object, but I
know it just really needs a string with the data to do the work.
Many people migrate to PHP from different languages, and mostly those
are strictly typed compile languages (I actually had teached PHP for 2
years at the private school of web technologies - I saw many people
learning PHP after Java, C++, Delphi, even assembler).
It's not the problem that will become a problem in a year or two - it
will become so in 5-7 years. Just like register_globals, magic_quotes
and things like that gave their evil effects in time.So please, take your time to think this through. The technical aspect
is only part of the puzzle. As they say "The road to hell is paved
with good intentions". And adding strict and weak type hinting
together is just plainly a very bad idea. It may be good for library
and framework writers (but not all of them agree on that), but to the
people using them it will be a headache.
Hey, Michael
This is by far the best possible way I read in the whole conversation.
I like the way of backwards-compatibility, error-reporting and so on.
This is would be very useful and would not disturb someone's
framework-combination.
This should be written down in a new RFC.
For all who want the strict types, you can write an error handler and
convert all you get into an exception :D
But then you'll end up with code-snippets like this (extracted from
Magento):
try {
$value = unserialize($optionValue);
} catch (Exception $e) {
$value = $optionValue;
}
Sorry but I had to mention it somewhere ;) This is by far the worst and
most complex code-snippet I've seen ever. It relies on the hidden feature
that the error-handler converts all errors into an exception - but only in
DEV mode :D Therefore it works for all developers but on in the live-mode :D
Bye
Simon
2012/2/28 Michael Morris dmgx.michael@gmail.com
I don't want it to be a strongly typed language. Whatever you call it
(weakly typed, loosely typed), I want a change to where the option
to declare a datatype exists. I do not want it to be required, both
for backwards compatibility and also for barrier to entry reasons.In my mind given: (this is one continuous example)
$a = 123;
And given the function
function foo ( int $i ) {}
Then if we call
foo($a);
We are ok. If we call
foo("123")
We are still ok, since the conversion of "123" to 123 is non-lossy. We
get a notice though, because unlike $a, which is a scalar, "123" is an
explicit string value.$a = "456";
foo($a);We are ok, and no notice is raised. $a is a scalar. It is the
datatype it needs to be to fulfill the request.int $a = 123;
A is now type locked to integer. So
$a = "456";
will raise an E_Notice and so will
$a = "Hello World";
If we want $a to go back to being a scalar one might try...
unset($a);
$a = "Hello World";And yes, $a is starting all over here because of the unset.
int $a;
$a had a value which can't convert without loss of data, E_NOTICE.
scalar $a;
And if we don't want to unset $a but rather restore $a to behaving
like a scalar, that is how it would be done. We can of course
formally declare scalars at all times, and I imagine some programmers
will do this for self documenting code reasons, but the scalar keyword
would only be needed if an existing variable needed it's type
unlocked. Meanwhile, remember that foo function above.$a = "456"
foo($a);As proposed, works, no error as discussed above.
$a = "Hello World";
foo($a);
E_NOTICEraised.string $a;
foo($a);
E_WARNINGraised. The reason for this higher error state to be raised
is an attempt was made to place an explicit string into an explicit
integer. That shouldn't occur. Code proceeds by doing the conversion.So, in closing this ramble, if I right a db library whose functions
are datatyped you might see more notices, but the code will work and
notices are usually suppressed by default (yes, I know about the RFC
to change that)On Tue, Feb 28, 2012 at 9:35 AM, Lazare Inepologlou linepogl@gmail.com
wrote:Hello everyone,
Let's stop the religious war between strongly and weekly typed languages.
In software, there is no silver bullet. Both approaches have their
benefits
and their disadvantages, so trying to prove that one is better to the
other
leads to nowhere.Having said that, I don't think that PHP will any time soon become a
strongly typed language. However, as there are indeed benefits to
strongly
typed languages, I see no reason to just close the door. I think it's
high
time that we separated the PHP platform from the PHP language. That
will eventually lead to the creation of strongly typed languages that
could
be executed on the PHP platform.Just my two cents :-)
Lazare INEPOLOGLOU
Ingénieur Logiciel2012/2/28 Arvids Godjuks arvids.godjuks@gmail.com
Aren't you people getting tired of saying that arguments like "it's
not the PHP way" or "that does not fit the PHP paradigm" are invalid.
Are you even aware, that language is not only about the features, but
is also about the paradigm, syntax, philosophy and methods of how it
achieves it's goals? It's not as simple as "nah, lets add feature X,
it looks weird and alien, but who cares as long as it's cool!".
On the terminology - strict is strict, weak is weak. Writing a
statement at the start of the thread and adding a few new words will
make no difference. Because half the people will just skip it, or
didn't read carefully because it's not interesting and so on. Some
people on the list just assume that we are perfect beings and read
every line of what's written on the list (hell, I skim the text and
read only the important things. I have ~15 threads active in my
mailbox (only the internals, not counting other mail) and reading each
of it carefully will just take too long).Besides that - a scripting language is much easier to learn, use it
and learn it. Things like strict typing, strict type hinting and so on
are not as trivial to understand and learn unless you start with a
strict typed compiled language. When you deal with the script language
and loose variable typing you get used to being able to convert types
on the fly. And imagine the shock when you start using some strict
typed library and now you have to convert all your variables
explicitly. And now the code looks just like C/C++/Java/Delphi code -
type conversion statements all over the place. I sure don't want such
code. And not because it is hard to combine (or impossible) weak and
strict type hinting - that just does not suit a scripting language
created with loose/weak typing in the first place. And adding such
things will not improve the code - it will mess it up big time. I
don't know about you, but I have seen and worked with folks who did
some really weird things in PHP. An instrument like strict type
hinting will just give them the ability to write code that is plain
stupid. It will be just like OOP for the sake of OOP. Too many people
do not understand the philosophy behind the PHP and they build over
complex things and complain that they had to become "inventive" to be
able to do implement something from the C++/Java/Python/Ruby world.
And they complain that PHP is a bad language, but still eat the
cactus. I wonder why?I really liked what the O'Raily wrote here:
http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html
I know, some things are a little over the top, but in general it
describes the best PHP feature - it's easy to work with, it's easy to
make something without using any frameworks, libraries and just do the
work you need for the WEB.
And I think it should stay that way. And I personally like it that
way. And it's because of that I don't want to migrate to Ryby or
Python. Adding strict type hinting will ruin it because I know for a
fact that there are plenty of programmers who will turn their API's
into strict typed all over the place. And I will have to select my
data from the database and go through the records and explicitly
convert all my data to the correct types so I can use that wonderful
library whose author is a fond of strict typing. I see such things
with OOP right now in many places - they ask you for an object, but I
know it just really needs a string with the data to do the work.
Many people migrate to PHP from different languages, and mostly those
are strictly typed compile languages (I actually had teached PHP for 2
years at the private school of web technologies - I saw many people
learning PHP after Java, C++, Delphi, even assembler).
It's not the problem that will become a problem in a year or two - it
will become so in 5-7 years. Just like register_globals, magic_quotes
and things like that gave their evil effects in time.So please, take your time to think this through. The technical aspect
is only part of the puzzle. As they say "The road to hell is paved
with good intentions". And adding strict and weak type hinting
together is just plainly a very bad idea. It may be good for library
and framework writers (but not all of them agree on that), but to the
people using them it will be a headache.
Function type hints are ok, but I can't imagine a reason why would you
really use the "locked" variables in PHP?
Sure, there are cases where it can be used and opcode cachers can make
optimization based on code analysis (but the PHP core will never get
that for performance reasons - that PHP Core team said numerous times)
and code is much stricter on demands.
But could you really describe why it should be, because of the dynamic
nature of PHP it will have performance and memory footprint tradeoffs
(just see how the zval container is built) and you have to leave the
dynamic part in place. PHP team made an impressive job with PHP 5.4
with the execution speed and memory usage reduction (especially memory
usage reduction). And now you purpose to make it eat more memory again
and slow down with additional logic. Type hinting the functions will
not not make much of a impact, but strict typing the variables will
add checks on every single operation that can be done with a variable.
I imagine it will be chaos in the language core code checking if a
variable is strict typed or dynamic and executing relevant branch of
the code. And then with every addition to the language you have to
make sure that you don't break all the parts of the puzzle - means
double work. I do not know about PHP devs, but in my projects I do not
allow that to happen unless it's absolutely necessarily (and I
absolutely document that part of code, and revisit it with the re
factoring to get rid of it).
And I have to mention serialization. How would you serialize and
unserialize the locked (strictly typed?) variable? Without any
additional flags you can't. Huston - we have a problem! Serialize a
string with PHP X.0.0 and try to access it with PHP X-1.y.z and
everything breaks down. There was a relevant discussion about such
cases in the thread about adding ig_binary to the core and about the
serialize handlers as a whole. Hell, that is just one big can of worms
:)
2012/2/28 Michael Morris dmgx.michael@gmail.com:
I don't want it to be a strongly typed language. Whatever you call it
(weakly typed, loosely typed), I want a change to where the option
to declare a datatype exists. I do not want it to be required, both
for backwards compatibility and also for barrier to entry reasons.In my mind given: (this is one continuous example)
$a = 123;
And given the function
function foo ( int $i ) {}
Then if we call
foo($a);
We are ok. If we call
foo("123")
We are still ok, since the conversion of "123" to 123 is non-lossy. We
get a notice though, because unlike $a, which is a scalar, "123" is an
explicit string value.$a = "456";
foo($a);We are ok, and no notice is raised. $a is a scalar. It is the
datatype it needs to be to fulfill the request.int $a = 123;
A is now type locked to integer. So
$a = "456";
will raise an E_Notice and so will
$a = "Hello World";
If we want $a to go back to being a scalar one might try...
unset($a);
$a = "Hello World";And yes, $a is starting all over here because of the unset.
int $a;
$a had a value which can't convert without loss of data, E_NOTICE.
scalar $a;
And if we don't want to unset $a but rather restore $a to behaving
like a scalar, that is how it would be done. We can of course
formally declare scalars at all times, and I imagine some programmers
will do this for self documenting code reasons, but the scalar keyword
would only be needed if an existing variable needed it's type
unlocked. Meanwhile, remember that foo function above.$a = "456"
foo($a);As proposed, works, no error as discussed above.
$a = "Hello World";
foo($a);
E_NOTICEraised.string $a;
foo($a);
E_WARNINGraised. The reason for this higher error state to be raised
is an attempt was made to place an explicit string into an explicit
integer. That shouldn't occur. Code proceeds by doing the conversion.So, in closing this ramble, if I right a db library whose functions
are datatyped you might see more notices, but the code will work and
notices are usually suppressed by default (yes, I know about the RFC
to change that)Hello everyone,
Let's stop the religious war between strongly and weekly typed languages.
In software, there is no silver bullet. Both approaches have their benefits
and their disadvantages, so trying to prove that one is better to the other
leads to nowhere.Having said that, I don't think that PHP will any time soon become a
strongly typed language. However, as there are indeed benefits to strongly
typed languages, I see no reason to just close the door. I think it's high
time that we separated the PHP platform from the PHP language. That
will eventually lead to the creation of strongly typed languages that could
be executed on the PHP platform.Just my two cents :-)
Lazare INEPOLOGLOU
Ingénieur Logiciel2012/2/28 Arvids Godjuks arvids.godjuks@gmail.com
Aren't you people getting tired of saying that arguments like "it's
not the PHP way" or "that does not fit the PHP paradigm" are invalid.
Are you even aware, that language is not only about the features, but
is also about the paradigm, syntax, philosophy and methods of how it
achieves it's goals? It's not as simple as "nah, lets add feature X,
it looks weird and alien, but who cares as long as it's cool!".
On the terminology - strict is strict, weak is weak. Writing a
statement at the start of the thread and adding a few new words will
make no difference. Because half the people will just skip it, or
didn't read carefully because it's not interesting and so on. Some
people on the list just assume that we are perfect beings and read
every line of what's written on the list (hell, I skim the text and
read only the important things. I have ~15 threads active in my
mailbox (only the internals, not counting other mail) and reading each
of it carefully will just take too long).Besides that - a scripting language is much easier to learn, use it
and learn it. Things like strict typing, strict type hinting and so on
are not as trivial to understand and learn unless you start with a
strict typed compiled language. When you deal with the script language
and loose variable typing you get used to being able to convert types
on the fly. And imagine the shock when you start using some strict
typed library and now you have to convert all your variables
explicitly. And now the code looks just like C/C++/Java/Delphi code -
type conversion statements all over the place. I sure don't want such
code. And not because it is hard to combine (or impossible) weak and
strict type hinting - that just does not suit a scripting language
created with loose/weak typing in the first place. And adding such
things will not improve the code - it will mess it up big time. I
don't know about you, but I have seen and worked with folks who did
some really weird things in PHP. An instrument like strict type
hinting will just give them the ability to write code that is plain
stupid. It will be just like OOP for the sake of OOP. Too many people
do not understand the philosophy behind the PHP and they build over
complex things and complain that they had to become "inventive" to be
able to do implement something from the C++/Java/Python/Ruby world.
And they complain that PHP is a bad language, but still eat the
cactus. I wonder why?I really liked what the O'Raily wrote here:
http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html
I know, some things are a little over the top, but in general it
describes the best PHP feature - it's easy to work with, it's easy to
make something without using any frameworks, libraries and just do the
work you need for the WEB.
And I think it should stay that way. And I personally like it that
way. And it's because of that I don't want to migrate to Ryby or
Python. Adding strict type hinting will ruin it because I know for a
fact that there are plenty of programmers who will turn their API's
into strict typed all over the place. And I will have to select my
data from the database and go through the records and explicitly
convert all my data to the correct types so I can use that wonderful
library whose author is a fond of strict typing. I see such things
with OOP right now in many places - they ask you for an object, but I
know it just really needs a string with the data to do the work.
Many people migrate to PHP from different languages, and mostly those
are strictly typed compile languages (I actually had teached PHP for 2
years at the private school of web technologies - I saw many people
learning PHP after Java, C++, Delphi, even assembler).
It's not the problem that will become a problem in a year or two - it
will become so in 5-7 years. Just like register_globals, magic_quotes
and things like that gave their evil effects in time.So please, take your time to think this through. The technical aspect
is only part of the puzzle. As they say "The road to hell is paved
with good intentions". And adding strict and weak type hinting
together is just plainly a very bad idea. It may be good for library
and framework writers (but not all of them agree on that), but to the
people using them it will be a headache.
Hi, Arvids
I do understand your arguments ...
For me personally it's mostly to separate between string and numbers. A
string to number transformation is most-likely not without loosing
something ... This is most likely the reason why I want to have a E_STRICT
or E_NOTICE if something like that happens. Same appears to a
transformation of a number to Boolean.
I don't really care how variables are handled in the very inner part of the
php-core as long as it's effective ;)
As you're talking about serialization ... that's right ... If you're
serializing an array containing strict variables would require a change.
Here you'll have a big downwards-compatibility-break ...
We can do this discussion endless ... but I think you got the point why I
want something like this.
Until now I trusted my IDE (PhpStorm) that's reading the PhpDoc of a
function and marking it as warning if I try to put in an integer whereas
the documentation says that this function expects a string (or an error if
it should be an object or array).
Bye
Simon
2012/2/28 Arvids Godjuks arvids.godjuks@gmail.com
Function type hints are ok, but I can't imagine a reason why would you
really use the "locked" variables in PHP?
Sure, there are cases where it can be used and opcode cachers can make
optimization based on code analysis (but the PHP core will never get
that for performance reasons - that PHP Core team said numerous times)
and code is much stricter on demands.
But could you really describe why it should be, because of the dynamic
nature of PHP it will have performance and memory footprint tradeoffs
(just see how the zval container is built) and you have to leave the
dynamic part in place. PHP team made an impressive job with PHP 5.4
with the execution speed and memory usage reduction (especially memory
usage reduction). And now you purpose to make it eat more memory again
and slow down with additional logic. Type hinting the functions will
not not make much of a impact, but strict typing the variables will
add checks on every single operation that can be done with a variable.
I imagine it will be chaos in the language core code checking if a
variable is strict typed or dynamic and executing relevant branch of
the code. And then with every addition to the language you have to
make sure that you don't break all the parts of the puzzle - means
double work. I do not know about PHP devs, but in my projects I do not
allow that to happen unless it's absolutely necessarily (and I
absolutely document that part of code, and revisit it with the re
factoring to get rid of it).
And I have to mention serialization. How would you serialize and
unserialize the locked (strictly typed?) variable? Without any
additional flags you can't. Huston - we have a problem! Serialize a
string with PHP X.0.0 and try to access it with PHP X-1.y.z and
everything breaks down. There was a relevant discussion about such
cases in the thread about adding ig_binary to the core and about the
serialize handlers as a whole. Hell, that is just one big can of worms
:)2012/2/28 Michael Morris dmgx.michael@gmail.com:
I don't want it to be a strongly typed language. Whatever you call it
(weakly typed, loosely typed), I want a change to where the option
to declare a datatype exists. I do not want it to be required, both
for backwards compatibility and also for barrier to entry reasons.In my mind given: (this is one continuous example)
$a = 123;
And given the function
function foo ( int $i ) {}
Then if we call
foo($a);
We are ok. If we call
foo("123")
We are still ok, since the conversion of "123" to 123 is non-lossy. We
get a notice though, because unlike $a, which is a scalar, "123" is an
explicit string value.$a = "456";
foo($a);We are ok, and no notice is raised. $a is a scalar. It is the
datatype it needs to be to fulfill the request.int $a = 123;
A is now type locked to integer. So
$a = "456";
will raise an E_Notice and so will
$a = "Hello World";
If we want $a to go back to being a scalar one might try...
unset($a);
$a = "Hello World";And yes, $a is starting all over here because of the unset.
int $a;
$a had a value which can't convert without loss of data, E_NOTICE.
scalar $a;
And if we don't want to unset $a but rather restore $a to behaving
like a scalar, that is how it would be done. We can of course
formally declare scalars at all times, and I imagine some programmers
will do this for self documenting code reasons, but the scalar keyword
would only be needed if an existing variable needed it's type
unlocked. Meanwhile, remember that foo function above.$a = "456"
foo($a);As proposed, works, no error as discussed above.
$a = "Hello World";
foo($a);
E_NOTICEraised.string $a;
foo($a);
E_WARNINGraised. The reason for this higher error state to be raised
is an attempt was made to place an explicit string into an explicit
integer. That shouldn't occur. Code proceeds by doing the conversion.So, in closing this ramble, if I right a db library whose functions
are datatyped you might see more notices, but the code will work and
notices are usually suppressed by default (yes, I know about the RFC
to change that)On Tue, Feb 28, 2012 at 9:35 AM, Lazare Inepologlou linepogl@gmail.com
wrote:Hello everyone,
Let's stop the religious war between strongly and weekly typed
languages.
In software, there is no silver bullet. Both approaches have their
benefits
and their disadvantages, so trying to prove that one is better to the
other
leads to nowhere.Having said that, I don't think that PHP will any time soon become a
strongly typed language. However, as there are indeed benefits to
strongly
typed languages, I see no reason to just close the door. I think it's
high
time that we separated the PHP platform from the PHP language. That
will eventually lead to the creation of strongly typed languages that
could
be executed on the PHP platform.Just my two cents :-)
Lazare INEPOLOGLOU
Ingénieur Logiciel2012/2/28 Arvids Godjuks arvids.godjuks@gmail.com
Aren't you people getting tired of saying that arguments like "it's
not the PHP way" or "that does not fit the PHP paradigm" are invalid.
Are you even aware, that language is not only about the features, but
is also about the paradigm, syntax, philosophy and methods of how it
achieves it's goals? It's not as simple as "nah, lets add feature X,
it looks weird and alien, but who cares as long as it's cool!".
On the terminology - strict is strict, weak is weak. Writing a
statement at the start of the thread and adding a few new words will
make no difference. Because half the people will just skip it, or
didn't read carefully because it's not interesting and so on. Some
people on the list just assume that we are perfect beings and read
every line of what's written on the list (hell, I skim the text and
read only the important things. I have ~15 threads active in my
mailbox (only the internals, not counting other mail) and reading each
of it carefully will just take too long).Besides that - a scripting language is much easier to learn, use it
and learn it. Things like strict typing, strict type hinting and so on
are not as trivial to understand and learn unless you start with a
strict typed compiled language. When you deal with the script language
and loose variable typing you get used to being able to convert types
on the fly. And imagine the shock when you start using some strict
typed library and now you have to convert all your variables
explicitly. And now the code looks just like C/C++/Java/Delphi code -
type conversion statements all over the place. I sure don't want such
code. And not because it is hard to combine (or impossible) weak and
strict type hinting - that just does not suit a scripting language
created with loose/weak typing in the first place. And adding such
things will not improve the code - it will mess it up big time. I
don't know about you, but I have seen and worked with folks who did
some really weird things in PHP. An instrument like strict type
hinting will just give them the ability to write code that is plain
stupid. It will be just like OOP for the sake of OOP. Too many people
do not understand the philosophy behind the PHP and they build over
complex things and complain that they had to become "inventive" to be
able to do implement something from the C++/Java/Python/Ruby world.
And they complain that PHP is a bad language, but still eat the
cactus. I wonder why?I really liked what the O'Raily wrote here:
http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html
I know, some things are a little over the top, but in general it
describes the best PHP feature - it's easy to work with, it's easy to
make something without using any frameworks, libraries and just do the
work you need for the WEB.
And I think it should stay that way. And I personally like it that
way. And it's because of that I don't want to migrate to Ryby or
Python. Adding strict type hinting will ruin it because I know for a
fact that there are plenty of programmers who will turn their API's
into strict typed all over the place. And I will have to select my
data from the database and go through the records and explicitly
convert all my data to the correct types so I can use that wonderful
library whose author is a fond of strict typing. I see such things
with OOP right now in many places - they ask you for an object, but I
know it just really needs a string with the data to do the work.
Many people migrate to PHP from different languages, and mostly those
are strictly typed compile languages (I actually had teached PHP for 2
years at the private school of web technologies - I saw many people
learning PHP after Java, C++, Delphi, even assembler).
It's not the problem that will become a problem in a year or two - it
will become so in 5-7 years. Just like register_globals, magic_quotes
and things like that gave their evil effects in time.So please, take your time to think this through. The technical aspect
is only part of the puzzle. As they say "The road to hell is paved
with good intentions". And adding strict and weak type hinting
together is just plainly a very bad idea. It may be good for library
and framework writers (but not all of them agree on that), but to the
people using them it will be a headache.
There are indeed valid arguments for and against hinting. It seems to me
that having it optional as people have suggested would be the "best of both
worlds" approach, since it would allow the developer to choose for
themselves. I guess that means I'm on the "pro-choice" side of this debate
lol (seriously, all kidding aside, I've seen debates over abortion that
weren't as heated as this!).
--Kris
On Tue, Feb 28, 2012 at 10:35 AM, Simon Schick
simonsimcity@googlemail.comwrote:
Hi, Arvids
I do understand your arguments ...
For me personally it's mostly to separate between string and numbers. A
string to number transformation is most-likely not without loosing
something ... This is most likely the reason why I want to have aE_STRICT
orE_NOTICEif something like that happens. Same appears to a
transformation of a number to Boolean.
I don't really care how variables are handled in the very inner part of the
php-core as long as it's effective ;)As you're talking about serialization ... that's right ... If you're
serializing an array containing strict variables would require a change.
Here you'll have a big downwards-compatibility-break ...We can do this discussion endless ... but I think you got the point why I
want something like this.
Until now I trusted my IDE (PhpStorm) that's reading the PhpDoc of a
function and marking it as warning if I try to put in an integer whereas
the documentation says that this function expects a string (or an error if
it should be an object or array).Bye
Simon2012/2/28 Arvids Godjuks arvids.godjuks@gmail.com
Function type hints are ok, but I can't imagine a reason why would you
really use the "locked" variables in PHP?
Sure, there are cases where it can be used and opcode cachers can make
optimization based on code analysis (but the PHP core will never get
that for performance reasons - that PHP Core team said numerous times)
and code is much stricter on demands.
But could you really describe why it should be, because of the dynamic
nature of PHP it will have performance and memory footprint tradeoffs
(just see how the zval container is built) and you have to leave the
dynamic part in place. PHP team made an impressive job with PHP 5.4
with the execution speed and memory usage reduction (especially memory
usage reduction). And now you purpose to make it eat more memory again
and slow down with additional logic. Type hinting the functions will
not not make much of a impact, but strict typing the variables will
add checks on every single operation that can be done with a variable.
I imagine it will be chaos in the language core code checking if a
variable is strict typed or dynamic and executing relevant branch of
the code. And then with every addition to the language you have to
make sure that you don't break all the parts of the puzzle - means
double work. I do not know about PHP devs, but in my projects I do not
allow that to happen unless it's absolutely necessarily (and I
absolutely document that part of code, and revisit it with the re
factoring to get rid of it).
And I have to mention serialization. How would you serialize and
unserialize the locked (strictly typed?) variable? Without any
additional flags you can't. Huston - we have a problem! Serialize a
string with PHP X.0.0 and try to access it with PHP X-1.y.z and
everything breaks down. There was a relevant discussion about such
cases in the thread about adding ig_binary to the core and about the
serialize handlers as a whole. Hell, that is just one big can of worms
:)2012/2/28 Michael Morris dmgx.michael@gmail.com:
I don't want it to be a strongly typed language. Whatever you call it
(weakly typed, loosely typed), I want a change to where the option
to declare a datatype exists. I do not want it to be required, both
for backwards compatibility and also for barrier to entry reasons.In my mind given: (this is one continuous example)
$a = 123;
And given the function
function foo ( int $i ) {}
Then if we call
foo($a);
We are ok. If we call
foo("123")
We are still ok, since the conversion of "123" to 123 is non-lossy. We
get a notice though, because unlike $a, which is a scalar, "123" is an
explicit string value.$a = "456";
foo($a);We are ok, and no notice is raised. $a is a scalar. It is the
datatype it needs to be to fulfill the request.int $a = 123;
A is now type locked to integer. So
$a = "456";
will raise an E_Notice and so will
$a = "Hello World";
If we want $a to go back to being a scalar one might try...
unset($a);
$a = "Hello World";And yes, $a is starting all over here because of the unset.
int $a;
$a had a value which can't convert without loss of data, E_NOTICE.
scalar $a;
And if we don't want to unset $a but rather restore $a to behaving
like a scalar, that is how it would be done. We can of course
formally declare scalars at all times, and I imagine some programmers
will do this for self documenting code reasons, but the scalar keyword
would only be needed if an existing variable needed it's type
unlocked. Meanwhile, remember that foo function above.$a = "456"
foo($a);As proposed, works, no error as discussed above.
$a = "Hello World";
foo($a);
E_NOTICEraised.string $a;
foo($a);
E_WARNINGraised. The reason for this higher error state to be raised
is an attempt was made to place an explicit string into an explicit
integer. That shouldn't occur. Code proceeds by doing the conversion.So, in closing this ramble, if I right a db library whose functions
are datatyped you might see more notices, but the code will work and
notices are usually suppressed by default (yes, I know about the RFC
to change that)On Tue, Feb 28, 2012 at 9:35 AM, Lazare Inepologlou <
linepogl@gmail.com>
wrote:Hello everyone,
Let's stop the religious war between strongly and weekly typed
languages.
In software, there is no silver bullet. Both approaches have their
benefits
and their disadvantages, so trying to prove that one is better to the
other
leads to nowhere.Having said that, I don't think that PHP will any time soon become a
strongly typed language. However, as there are indeed benefits to
strongly
typed languages, I see no reason to just close the door. I think it's
high
time that we separated the PHP platform from the PHP language.
That
will eventually lead to the creation of strongly typed languages that
could
be executed on the PHP platform.Just my two cents :-)
Lazare INEPOLOGLOU
Ingénieur Logiciel2012/2/28 Arvids Godjuks arvids.godjuks@gmail.com
Aren't you people getting tired of saying that arguments like "it's
not the PHP way" or "that does not fit the PHP paradigm" are invalid.
Are you even aware, that language is not only about the features, but
is also about the paradigm, syntax, philosophy and methods of how it
achieves it's goals? It's not as simple as "nah, lets add feature X,
it looks weird and alien, but who cares as long as it's cool!".
On the terminology - strict is strict, weak is weak. Writing a
statement at the start of the thread and adding a few new words will
make no difference. Because half the people will just skip it, or
didn't read carefully because it's not interesting and so on. Some
people on the list just assume that we are perfect beings and read
every line of what's written on the list (hell, I skim the text and
read only the important things. I have ~15 threads active in my
mailbox (only the internals, not counting other mail) and reading
each
of it carefully will just take too long).Besides that - a scripting language is much easier to learn, use it
and learn it. Things like strict typing, strict type hinting and so
on
are not as trivial to understand and learn unless you start with a
strict typed compiled language. When you deal with the script
language
and loose variable typing you get used to being able to convert types
on the fly. And imagine the shock when you start using some strict
typed library and now you have to convert all your variables
explicitly. And now the code looks just like C/C++/Java/Delphi code -
type conversion statements all over the place. I sure don't want such
code. And not because it is hard to combine (or impossible) weak and
strict type hinting - that just does not suit a scripting language
created with loose/weak typing in the first place. And adding such
things will not improve the code - it will mess it up big time. I
don't know about you, but I have seen and worked with folks who did
some really weird things in PHP. An instrument like strict type
hinting will just give them the ability to write code that is plain
stupid. It will be just like OOP for the sake of OOP. Too many people
do not understand the philosophy behind the PHP and they build over
complex things and complain that they had to become "inventive" to be
able to do implement something from the C++/Java/Python/Ruby world.
And they complain that PHP is a bad language, but still eat the
cactus. I wonder why?I really liked what the O'Raily wrote here:
http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html
I know, some things are a little over the top, but in general it
describes the best PHP feature - it's easy to work with, it's easy to
make something without using any frameworks, libraries and just do
the
work you need for the WEB.
And I think it should stay that way. And I personally like it that
way. And it's because of that I don't want to migrate to Ryby or
Python. Adding strict type hinting will ruin it because I know for a
fact that there are plenty of programmers who will turn their API's
into strict typed all over the place. And I will have to select my
data from the database and go through the records and explicitly
convert all my data to the correct types so I can use that wonderful
library whose author is a fond of strict typing. I see such things
with OOP right now in many places - they ask you for an object, but I
know it just really needs a string with the data to do the work.
Many people migrate to PHP from different languages, and mostly those
are strictly typed compile languages (I actually had teached PHP for
2
years at the private school of web technologies - I saw many people
learning PHP after Java, C++, Delphi, even assembler).
It's not the problem that will become a problem in a year or two - it
will become so in 5-7 years. Just like register_globals, magic_quotes
and things like that gave their evil effects in time.So please, take your time to think this through. The technical aspect
is only part of the puzzle. As they say "The road to hell is paved
with good intentions". And adding strict and weak type hinting
together is just plainly a very bad idea. It may be good for library
and framework writers (but not all of them agree on that), but to the
people using them it will be a headache.
Additionally, return type hinting could strengthen the use of interfaces.
That could problems with implementing interfaces (or an API) from having
to do checking to ensure a method in a class implementing an interface
is behaving as it should (returning the right stuff).
Hi, Arvids
I do understand your arguments ...
For me personally it's mostly to separate between string and numbers. A
string to number transformation is most-likely not without loosing
something ... This is most likely the reason why I want to have aE_STRICT
orE_NOTICEif something like that happens. Same appears to a
transformation of a number to Boolean.
I don't really care how variables are handled in the very inner part of the
php-core as long as it's effective ;)As you're talking about serialization ... that's right ... If you're
serializing an array containing strict variables would require a change.
Here you'll have a big downwards-compatibility-break ...We can do this discussion endless ... but I think you got the point why I
want something like this.
Until now I trusted my IDE (PhpStorm) that's reading the PhpDoc of a
function and marking it as warning if I try to put in an integer whereas
the documentation says that this function expects a string (or an error if
it should be an object or array).Bye
Simon2012/2/28 Arvids Godjuksarvids.godjuks@gmail.com
Function type hints are ok, but I can't imagine a reason why would you
really use the "locked" variables in PHP?
Sure, there are cases where it can be used and opcode cachers can make
optimization based on code analysis (but the PHP core will never get
that for performance reasons - that PHP Core team said numerous times)
and code is much stricter on demands.
But could you really describe why it should be, because of the dynamic
nature of PHP it will have performance and memory footprint tradeoffs
(just see how the zval container is built) and you have to leave the
dynamic part in place. PHP team made an impressive job with PHP 5.4
with the execution speed and memory usage reduction (especially memory
usage reduction). And now you purpose to make it eat more memory again
and slow down with additional logic. Type hinting the functions will
not not make much of a impact, but strict typing the variables will
add checks on every single operation that can be done with a variable.
I imagine it will be chaos in the language core code checking if a
variable is strict typed or dynamic and executing relevant branch of
the code. And then with every addition to the language you have to
make sure that you don't break all the parts of the puzzle - means
double work. I do not know about PHP devs, but in my projects I do not
allow that to happen unless it's absolutely necessarily (and I
absolutely document that part of code, and revisit it with the re
factoring to get rid of it).
And I have to mention serialization. How would you serialize and
unserialize the locked (strictly typed?) variable? Without any
additional flags you can't. Huston - we have a problem! Serialize a
string with PHP X.0.0 and try to access it with PHP X-1.y.z and
everything breaks down. There was a relevant discussion about such
cases in the thread about adding ig_binary to the core and about the
serialize handlers as a whole. Hell, that is just one big can of worms
:)2012/2/28 Michael Morrisdmgx.michael@gmail.com:
I don't want it to be a strongly typed language. Whatever you call it
(weakly typed, loosely typed), I want a change to where the option
to declare a datatype exists. I do not want it to be required, both
for backwards compatibility and also for barrier to entry reasons.In my mind given: (this is one continuous example)
$a = 123;
And given the function
function foo ( int $i ) {}
Then if we call
foo($a);
We are ok. If we call
foo("123")
We are still ok, since the conversion of "123" to 123 is non-lossy. We
get a notice though, because unlike $a, which is a scalar, "123" is an
explicit string value.$a = "456";
foo($a);We are ok, and no notice is raised. $a is a scalar. It is the
datatype it needs to be to fulfill the request.int $a = 123;
A is now type locked to integer. So
$a = "456";
will raise an E_Notice and so will
$a = "Hello World";
If we want $a to go back to being a scalar one might try...
unset($a);
$a = "Hello World";And yes, $a is starting all over here because of the unset.
int $a;
$a had a value which can't convert without loss of data, E_NOTICE.
scalar $a;
And if we don't want to unset $a but rather restore $a to behaving
like a scalar, that is how it would be done. We can of course
formally declare scalars at all times, and I imagine some programmers
will do this for self documenting code reasons, but the scalar keyword
would only be needed if an existing variable needed it's type
unlocked. Meanwhile, remember that foo function above.$a = "456"
foo($a);As proposed, works, no error as discussed above.
$a = "Hello World";
foo($a);
E_NOTICEraised.string $a;
foo($a);
E_WARNINGraised. The reason for this higher error state to be raised
is an attempt was made to place an explicit string into an explicit
integer. That shouldn't occur. Code proceeds by doing the conversion.So, in closing this ramble, if I right a db library whose functions
are datatyped you might see more notices, but the code will work and
notices are usually suppressed by default (yes, I know about the RFC
to change that)On Tue, Feb 28, 2012 at 9:35 AM, Lazare Inepologloulinepogl@gmail.com
wrote:Hello everyone,
Let's stop the religious war between strongly and weekly typed
languages.
In software, there is no silver bullet. Both approaches have their
benefits
and their disadvantages, so trying to prove that one is better to the
other
leads to nowhere.Having said that, I don't think that PHP will any time soon become a
strongly typed language. However, as there are indeed benefits to
strongly
typed languages, I see no reason to just close the door. I think it's
high
time that we separated the PHP platform from the PHP language. That
will eventually lead to the creation of strongly typed languages that
could
be executed on the PHP platform.Just my two cents :-)
Lazare INEPOLOGLOU
Ingénieur Logiciel2012/2/28 Arvids Godjuksarvids.godjuks@gmail.com
Aren't you people getting tired of saying that arguments like "it's
not the PHP way" or "that does not fit the PHP paradigm" are invalid.
Are you even aware, that language is not only about the features, but
is also about the paradigm, syntax, philosophy and methods of how it
achieves it's goals? It's not as simple as "nah, lets add feature X,
it looks weird and alien, but who cares as long as it's cool!".
On the terminology - strict is strict, weak is weak. Writing a
statement at the start of the thread and adding a few new words will
make no difference. Because half the people will just skip it, or
didn't read carefully because it's not interesting and so on. Some
people on the list just assume that we are perfect beings and read
every line of what's written on the list (hell, I skim the text and
read only the important things. I have ~15 threads active in my
mailbox (only the internals, not counting other mail) and reading each
of it carefully will just take too long).Besides that - a scripting language is much easier to learn, use it
and learn it. Things like strict typing, strict type hinting and so on
are not as trivial to understand and learn unless you start with a
strict typed compiled language. When you deal with the script language
and loose variable typing you get used to being able to convert types
on the fly. And imagine the shock when you start using some strict
typed library and now you have to convert all your variables
explicitly. And now the code looks just like C/C++/Java/Delphi code -
type conversion statements all over the place. I sure don't want such
code. And not because it is hard to combine (or impossible) weak and
strict type hinting - that just does not suit a scripting language
created with loose/weak typing in the first place. And adding such
things will not improve the code - it will mess it up big time. I
don't know about you, but I have seen and worked with folks who did
some really weird things in PHP. An instrument like strict type
hinting will just give them the ability to write code that is plain
stupid. It will be just like OOP for the sake of OOP. Too many people
do not understand the philosophy behind the PHP and they build over
complex things and complain that they had to become "inventive" to be
able to do implement something from the C++/Java/Python/Ruby world.
And they complain that PHP is a bad language, but still eat the
cactus. I wonder why?I really liked what the O'Raily wrote here:
http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html
I know, some things are a little over the top, but in general it
describes the best PHP feature - it's easy to work with, it's easy to
make something without using any frameworks, libraries and just do the
work you need for the WEB.
And I think it should stay that way. And I personally like it that
way. And it's because of that I don't want to migrate to Ryby or
Python. Adding strict type hinting will ruin it because I know for a
fact that there are plenty of programmers who will turn their API's
into strict typed all over the place. And I will have to select my
data from the database and go through the records and explicitly
convert all my data to the correct types so I can use that wonderful
library whose author is a fond of strict typing. I see such things
with OOP right now in many places - they ask you for an object, but I
know it just really needs a string with the data to do the work.
Many people migrate to PHP from different languages, and mostly those
are strictly typed compile languages (I actually had teached PHP for 2
years at the private school of web technologies - I saw many people
learning PHP after Java, C++, Delphi, even assembler).
It's not the problem that will become a problem in a year or two - it
will become so in 5-7 years. Just like register_globals, magic_quotes
and things like that gave their evil effects in time.So please, take your time to think this through. The technical aspect
is only part of the puzzle. As they say "The road to hell is paved
with good intentions". And adding strict and weak type hinting
together is just plainly a very bad idea. It may be good for library
and framework writers (but not all of them agree on that), but to the
people using them it will be a headache.
Hi, Simon.
Actually I also advocated for notices/warnings on conversion with data loss.
What just has to be done - the rule table when notices/warnings are thrown.
What I have in mind is no variable type hinting at all. What I want to
see is function/method type hinting.
And, because the zval actually has type in it, you actually already
weakly type hint the variable anyway:
$a = 1;
echo gettype($a); // integer
$a = (int)"1";
echo gettype($a); // integer
$a = (string)1;
echo gettype($a); // string
And so on. This part is in the language, just has different syntax.
So no-no-no from me on this:
int $a = 1;
int $a = "1";
It just duplicates the functionality. And I don't like the strict int
$a = 1; I have already explained why it's not a good idea from the
technical standpoint.
So what I want is this:
function int test(int $a, int $b)
{
return $a * $b;
}
test(1, 2); // 2;
test("1", 2); // 2
test("1aaa", 2); // E_NOTICE or E_TYPE and result 2
test(array(2), 2); // E_RECOVERABLE_ERROR - just like with array type hint now.
It's really what the most people want. Simple, easy to pick up (object
and array already have this) and is just optional.
I purpose to deal with this and when it works and is released to the
wild then see if more strictness even is needed. I think this simple
weak type hinted functionality will suffice.
---------- Forwarded message ----------
From: Simon Schick simonsimcity@googlemail.com
Date: 2012/2/28
Subject: Re: [PHP-DEV] Scalar type hinting
To: Arvids Godjuks arvids.godjuks@gmail.com
Копия: Michael Morris dmgx.michael@gmail.com, internals@lists.php.net
Hi, Arvids
I do understand your arguments ...
For me personally it's mostly to separate between string and numbers.
A string to number transformation is most-likely not without loosing
something ... This is most likely the reason why I want to have a
E_STRICT or E_NOTICE if something like that happens. Same appears to a
transformation of a number to Boolean.
I don't really care how variables are handled in the very inner part
of the php-core as long as it's effective ;)
As you're talking about serialization ... that's right ... If you're
serializing an array containing strict variables would require a
change.
Here you'll have a big downwards-compatibility-break ...
We can do this discussion endless ... but I think you got the point
why I want something like this.
Until now I trusted my IDE (PhpStorm) that's reading the PhpDoc of a
function and marking it as warning if I try to put in an integer
whereas the documentation says that this function expects a string (or
an error if it should be an object or array).
Bye
Simon
Much of what you put forward here is why I don't want there to be a
weak/strong divide. We can do "weak". Strong not so much. Current
syntax allows
$a = (int) 3;
echo gettype($a); // integer
$a = 'Hello';
echo gettype($a); // string.
Under the new syntax this happens.
int $a = 3;
echo gettype($a); // integer
$a = 'Hello';
E_WARNING raised
echo gettype($a); // integer
In other words, once the variable's type is declared, it WILL NOT
CHANGE. If one doesn't want that behavior, don't declare a type, and
things will work as they always have.
On Tue, Feb 28, 2012 at 5:56 PM, Arvids Godjuks
arvids.godjuks@gmail.com wrote:
Hi, Simon.
Actually I also advocated for notices/warnings on conversion with data loss.
What just has to be done - the rule table when notices/warnings are thrown.What I have in mind is no variable type hinting at all. What I want to
see is function/method type hinting.
And, because the zval actually has type in it, you actually already
weakly type hint the variable anyway:$a = 1;
echo gettype($a); // integer$a = (int)"1";
echo gettype($a); // integer$a = (string)1;
echo gettype($a); // stringAnd so on. This part is in the language, just has different syntax.
So no-no-no from me on this:
int $a = 1;
int $a = "1";It just duplicates the functionality. And I don't like the strict int
$a = 1; I have already explained why it's not a good idea from the
technical standpoint.So what I want is this:
function int test(int $a, int $b)
{
return $a * $b;
}
test(1, 2); // 2;
test("1", 2); // 2
test("1aaa", 2); //E_NOTICEor E_TYPE and result 2
test(array(2), 2); //E_RECOVERABLE_ERROR- just like with array type hint now.It's really what the most people want. Simple, easy to pick up (object
and array already have this) and is just optional.I purpose to deal with this and when it works and is released to the
wild then see if more strictness even is needed. I think this simple
weak type hinted functionality will suffice.---------- Forwarded message ----------
From: Simon Schick simonsimcity@googlemail.com
Date: 2012/2/28
Subject: Re: [PHP-DEV] Scalar type hinting
To: Arvids Godjuks arvids.godjuks@gmail.com
Копия: Michael Morris dmgx.michael@gmail.com, internals@lists.php.netHi, Arvids
I do understand your arguments ...
For me personally it's mostly to separate between string and numbers.
A string to number transformation is most-likely not without loosing
something ... This is most likely the reason why I want to have a
E_STRICTorE_NOTICEif something like that happens. Same appears to a
transformation of a number to Boolean.
I don't really care how variables are handled in the very inner part
of the php-core as long as it's effective ;)As you're talking about serialization ... that's right ... If you're
serializing an array containing strict variables would require a
change.
Here you'll have a big downwards-compatibility-break ...We can do this discussion endless ... but I think you got the point
why I want something like this.
Until now I trusted my IDE (PhpStorm) that's reading the PhpDoc of a
function and marking it as warning if I try to put in an integer
whereas the documentation says that this function expects a string (or
an error if it should be an object or array).Bye
Simon
One thing I've been noticing, and I think we should be careful of in this
discussion, is making broad "....and this is what most people want"
statements. I've heard a number of people make some variation of that
claim now to support at-times radically different approaches. So, unless
most people want everything, including the things that directly
contradict one another, then I think it's safe to say that some of us are
giving in to the temptation to use hyperbole. It's understandable and I've
probably done it myself on more than one occasion. But I think we have to
be careful not to make such claims unless we actually have data to back
them up.
None of us can credibly state that one approach or another is supported
by "most people" or "most developers," etc. Unless somebody can product a
scientific poll on the subject, there is no clear majority consensus on
this. If there was, we wouldn't still be having this discussion after so
many years.
So please, let's all be careful not to make baseless claims about "most
(insert plural noun here)" supporting one idea or another. All it does is
add needless confusion and clutter to an already complex issue.
--Kris
On Tue, Feb 28, 2012 at 2:56 PM, Arvids Godjuks arvids.godjuks@gmail.comwrote:
Hi, Simon.
Actually I also advocated for notices/warnings on conversion with data
loss.
What just has to be done - the rule table when notices/warnings are thrown.What I have in mind is no variable type hinting at all. What I want to
see is function/method type hinting.
And, because the zval actually has type in it, you actually already
weakly type hint the variable anyway:$a = 1;
echo gettype($a); // integer$a = (int)"1";
echo gettype($a); // integer$a = (string)1;
echo gettype($a); // stringAnd so on. This part is in the language, just has different syntax.
So no-no-no from me on this:
int $a = 1;
int $a = "1";It just duplicates the functionality. And I don't like the strict int
$a = 1; I have already explained why it's not a good idea from the
technical standpoint.So what I want is this:
function int test(int $a, int $b)
{
return $a * $b;
}
test(1, 2); // 2;
test("1", 2); // 2
test("1aaa", 2); //E_NOTICEor E_TYPE and result 2
test(array(2), 2); //E_RECOVERABLE_ERROR- just like with array type hint
now.It's really what the most people want. Simple, easy to pick up (object
and array already have this) and is just optional.I purpose to deal with this and when it works and is released to the
wild then see if more strictness even is needed. I think this simple
weak type hinted functionality will suffice.---------- Forwarded message ----------
From: Simon Schick simonsimcity@googlemail.com
Date: 2012/2/28
Subject: Re: [PHP-DEV] Scalar type hinting
To: Arvids Godjuks arvids.godjuks@gmail.com
Копия: Michael Morris dmgx.michael@gmail.com, internals@lists.php.netHi, Arvids
I do understand your arguments ...
For me personally it's mostly to separate between string and numbers.
A string to number transformation is most-likely not without loosing
something ... This is most likely the reason why I want to have a
E_STRICTorE_NOTICEif something like that happens. Same appears to a
transformation of a number to Boolean.
I don't really care how variables are handled in the very inner part
of the php-core as long as it's effective ;)As you're talking about serialization ... that's right ... If you're
serializing an array containing strict variables would require a
change.
Here you'll have a big downwards-compatibility-break ...We can do this discussion endless ... but I think you got the point
why I want something like this.
Until now I trusted my IDE (PhpStorm) that's reading the PhpDoc of a
function and marking it as warning if I try to put in an integer
whereas the documentation says that this function expects a string (or
an error if it should be an object or array).Bye
Simon
Inline. Quoted portion edited extensively for brevity.
-----Original Message-----
From: Michael Morris [mailto:dmgx.michael@gmail.com]$a = 123;
function foo ( int $i ) {}
foo($a); // OKfoo("123"); // NOTICE, because "123" is a constant
$a = "456";
foo($a); // OK, because conversion is lossless
-1. Should be no notice in either of the last two cases. Raising the notice when a constant is used is inconsistent and confusing. I also doubt that this sort of implementation is even possible without some pretty massive internal changes. Not worth it IMO.
int $a = 123; // "type locked" to integer
$a = "456"; //
E_NOTICE$a = "Hello World"; //
E_NOTICE
I'm very dubious on hinting variables. This would require storing additional data with the variable, which (as far as I can see) would break binary compatibility (same problem as taint). I don't see much of a use for this most of the time, with the notable exception of member variables (sometimes type locking a class member would be really nice.)
Also, there should be no notice in case 2 (same argument as before with functions)
Notice on case 3 is fine
unset($a);
$a = "Hello World"; // OK, because of unsetint $a; // E_NOTICE, $a had a value which can't convert without loss of data.
This just seems silly to me. Trying to declare int $a after $a is already present and set is a nonsense construct. I think E_RECOVERABLE_ERROR should be raised on this and $a should be set to null regardless of convertibility (the more likely intent and meaning of that line of code) in case the error handler decides to continue execution.
scalar $a;
-1, I don't think we need this any more than we need an explicit "mixed" type. Saying "this function needs a number or it can't work" is one thing. There is a sound logical foundation for that. A scalar could be anything though. You're still going to have to check types to decide what you really have and alter code paths as appropriate.
And if we don't want to unset $a but rather restore $a to behaving like a
scalar, that is how it would be done.
-1, same argument as int $a; when $a is already set. This is a nonsensical construction. You are using a variable declaration like a typecast and reusing a variable. This is sloppy and confusing to reduce code in a badly structured edge case. If you really honestly must untype a local variable, you can always do this instead:
$tmp = $a;
unset($a);
$a = $tmp;
BUT, if there is any reason why you would actually need to untype a variable, then there are much bigger problems. This shouldn't be handled in the core language.
So, in closing this ramble, if I right a db library whose functions are datatyped
you might see more notices, but the code will work and notices are usually suppressed
by default (yes, I know about the RFC to change that)
If using types causes a large number of unnecessary notices that's a spec problem. The core devs aren't going to accept that.
John Crenshaw
Priacta, Inc.
OK everyone, it seems that some people have forgotten or missed the original agreement that this thread started with. There is a communication disconnect ("strict typing" means horribly different things to different people right now). Please read through and understand the following terminology before continuing to post on this thread. We've agreed to the following terms:
- "Strict Typing" means the super strict old C style typing with no implicit conversions. (If you really think this is what you want, you are probably mistaken. Look through prior discussions on this topic. This fails for numerous reasons, including the fact that almost every input to PHP is a string.)
- "Weak Typing" means types in the same sense that the PHP documentation uses types (for example, the docs indicate substr(string, integer), and substr(12345, "2") == "345".) (If you think you want "strict typing", this is probably what you mean.)
- "No Scalar Typing" should be used to indicate the current system (where there is no provision for hinting at scalar types.)
In addition, if someone potentially new expresses support for "Strict Typing", please assume that they really mean weak typing unless proven otherwise (this is by far the more likely intent.) Don't get mean, politely clarify terminology so that everyone can be on the same page. If someone still insists that they want "Strict Typing" (as defined above), point them to the prior discussions on the topic which explain exactly what the problems with this are.
John Crenshaw
Priacta, Inc.
Thank you.
Now I'm going to go work up a detailed RFC for what I posted earlier
with some additional clarification as to when errors should and
shouldn't be thrown.
OK everyone, it seems that some people have forgotten or missed the original agreement that this thread started with. There is a communication disconnect ("strict typing" means horribly different things to different people right now). Please read through and understand the following terminology before continuing to post on this thread. We've agreed to the following terms:
- "Strict Typing" means the super strict old C style typing with no implicit conversions. (If you really think this is what you want, you are probably mistaken. Look through prior discussions on this topic. This fails for numerous reasons, including the fact that almost every input to PHP is a string.)
- "Weak Typing" means types in the same sense that the PHP documentation uses types (for example, the docs indicate substr(string, integer), and substr(12345, "2") == "345".) (If you think you want "strict typing", this is probably what you mean.)
- "No Scalar Typing" should be used to indicate the current system (where there is no provision for hinting at scalar types.)
In addition, if someone potentially new expresses support for "Strict Typing", please assume that they really mean weak typing unless proven otherwise (this is by far the more likely intent.) Don't get mean, politely clarify terminology so that everyone can be on the same page. If someone still insists that they want "Strict Typing" (as defined above), point them to the prior discussions on the topic which explain exactly what the problems with this are.
John Crenshaw
Priacta, Inc.
@Michael Would you be willing to delay that? Rather than create a bunch of
new RFC's, I was thinking it might be better if all interested parties came
together on some other communication medium and worked on a single,
collaborative RFC instead.
--Kris
On Tue, Feb 28, 2012 at 12:00 PM, Michael Morris dmgx.michael@gmail.comwrote:
Thank you.
Now I'm going to go work up a detailed RFC for what I posted earlier
with some additional clarification as to when errors should and
shouldn't be thrown.On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw johncrenshaw@priacta.com
wrote:OK everyone, it seems that some people have forgotten or missed the
original agreement that this thread started with. There is a communication
disconnect ("strict typing" means horribly different things to different
people right now). Please read through and understand the following
terminology before continuing to post on this thread. We've agreed to the
following terms:
- "Strict Typing" means the super strict old C style typing with no
implicit conversions. (If you really think this is what you want, you are
probably mistaken. Look through prior discussions on this topic. This fails
for numerous reasons, including the fact that almost every input to PHP is
a string.)- "Weak Typing" means types in the same sense that the PHP documentation
uses types (for example, the docs indicate substr(string, integer), and
substr(12345, "2") == "345".) (If you think you want "strict typing", this
is probably what you mean.)- "No Scalar Typing" should be used to indicate the current system
(where there is no provision for hinting at scalar types.)In addition, if someone potentially new expresses support for "Strict
Typing", please assume that they really mean weak typing unless proven
otherwise (this is by far the more likely intent.) Don't get mean, politely
clarify terminology so that everyone can be on the same page. If someone
still insists that they want "Strict Typing" (as defined above), point them
to the prior discussions on the topic which explain exactly what the
problems with this are.John Crenshaw
Priacta, Inc.
Can I make a suggestion? Instead of an rfc, can we collate the existing
discussion into an easier to digest format (historical as well). Summarize
the conversations and existing rfcs with the discussion around them
(including the pros/cons and problems). That way we have a point of
reference and comparison with which to base the rfc on, and a way to judge
and rate the rfc...
Anthony
@Michael Would you be willing to delay that? Rather than create a bunch of
new RFC's, I was thinking it might be better if all interested parties came
together on some other communication medium and worked on a single,
collaborative RFC instead.--Kris
On Tue, Feb 28, 2012 at 12:00 PM, Michael Morris <dmgx.michael@gmail.com
wrote:
Thank you.
Now I'm going to go work up a detailed RFC for what I posted earlier
with some additional clarification as to when errors should and
shouldn't be thrown.On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw <johncrenshaw@priacta.com
wrote:
OK everyone, it seems that some people have forgotten or missed the
original agreement that this thread started with. There is a
communication
disconnect ("strict typing" means horribly different things to different
people right now). Please read through and understand the following
terminology before continuing to post on this thread. We've agreed to the
following terms:
- "Strict Typing" means the super strict old C style typing with no
implicit conversions. (If you really think this is what you want, you
are
probably mistaken. Look through prior discussions on this topic. This
fails
for numerous reasons, including the fact that almost every input to PHP
is
a string.)- "Weak Typing" means types in the same sense that the PHP
documentation
uses types (for example, the docs indicate substr(string, integer), and
substr(12345, "2") == "345".) (If you think you want "strict typing",
this
is probably what you mean.)- "No Scalar Typing" should be used to indicate the current system
(where there is no provision for hinting at scalar types.)In addition, if someone potentially new expresses support for "Strict
Typing", please assume that they really mean weak typing unless proven
otherwise (this is by far the more likely intent.) Don't get mean,
politely
clarify terminology so that everyone can be on the same page. If someone
still insists that they want "Strict Typing" (as defined above), point
them
to the prior discussions on the topic which explain exactly what the
problems with this are.John Crenshaw
Priacta, Inc.
Yeah, I proposed this the other day. We need to go through the hundreds of historical emails on the subject and consolidate all the information into a central document outlining all the information that has been developed over the years. Lots of benefits to this. If multiple people want to participate in this process we can probably partition it by date ranges.
John Crenshaw
Priacta, Inc.
-----Original Message-----
From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
Sent: Tuesday, February 28, 2012 3:15 PM
To: Kris Craig
Cc: internals@lists.php.net; Arvids Godjuks; Michael Morris; Lazare Inepologlou
Subject: Re: [PHP-DEV] Scalar type hinting
Can I make a suggestion? Instead of an rfc, can we collate the existing discussion into an easier to digest format (historical as well). Summarize the conversations and existing rfcs with the discussion around them (including the pros/cons and problems). That way we have a point of reference and comparison with which to base the rfc on, and a way to judge and rate the rfc...
Anthony
@Michael Would you be willing to delay that? Rather than create a
bunch of new RFC's, I was thinking it might be better if all
interested parties came together on some other communication medium
and worked on a single, collaborative RFC instead.--Kris
On Tue, Feb 28, 2012 at 12:00 PM, Michael Morris
<dmgx.michael@gmail.comwrote:
Thank you.
Now I'm going to go work up a detailed RFC for what I posted earlier
with some additional clarification as to when errors should and
shouldn't be thrown.On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw
<johncrenshaw@priacta.comwrote:
OK everyone, it seems that some people have forgotten or missed
the
original agreement that this thread started with. There is a
communication
disconnect ("strict typing" means horribly different things to
different people right now). Please read through and understand the
following terminology before continuing to post on this thread.
We've agreed to the following terms:
- "Strict Typing" means the super strict old C style typing with
no
implicit conversions. (If you really think this is what you want,
you
are
probably mistaken. Look through prior discussions on this topic.
This
fails
for numerous reasons, including the fact that almost every input to
PHP
is
a string.)- "Weak Typing" means types in the same sense that the PHP
documentation
uses types (for example, the docs indicate substr(string, integer),
and substr(12345, "2") == "345".) (If you think you want "strict
typing",
this
is probably what you mean.)- "No Scalar Typing" should be used to indicate the current system
(where there is no provision for hinting at scalar types.)In addition, if someone potentially new expresses support for
"Strict
Typing", please assume that they really mean weak typing unless
proven otherwise (this is by far the more likely intent.) Don't get
mean,
politely
clarify terminology so that everyone can be on the same page. If
someone still insists that they want "Strict Typing" (as defined
above), point
them
to the prior discussions on the topic which explain exactly what the
problems with this are.John Crenshaw
Priacta, Inc.--
To unsubscribe,
visit: http://www.php.net/unsub.php
I could setup a repo on Github for this if anyone thinks that would be
helpful?
--Kris
On Tue, Feb 28, 2012 at 1:05 PM, John Crenshaw johncrenshaw@priacta.comwrote:
Yeah, I proposed this the other day. We need to go through the hundreds of
historical emails on the subject and consolidate all the information into a
central document outlining all the information that has been developed over
the years. Lots of benefits to this. If multiple people want to participate
in this process we can probably partition it by date ranges.John Crenshaw
Priacta, Inc.-----Original Message-----
From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
Sent: Tuesday, February 28, 2012 3:15 PM
To: Kris Craig
Cc: internals@lists.php.net; Arvids Godjuks; Michael Morris; Lazare
Inepologlou
Subject: Re: [PHP-DEV] Scalar type hintingCan I make a suggestion? Instead of an rfc, can we collate the existing
discussion into an easier to digest format (historical as well). Summarize
the conversations and existing rfcs with the discussion around them
(including the pros/cons and problems). That way we have a point of
reference and comparison with which to base the rfc on, and a way to judge
and rate the rfc...Anthony
@Michael Would you be willing to delay that? Rather than create a
bunch of new RFC's, I was thinking it might be better if all
interested parties came together on some other communication medium
and worked on a single, collaborative RFC instead.--Kris
On Tue, Feb 28, 2012 at 12:00 PM, Michael Morris
<dmgx.michael@gmail.comwrote:
Thank you.
Now I'm going to go work up a detailed RFC for what I posted earlier
with some additional clarification as to when errors should and
shouldn't be thrown.On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw
<johncrenshaw@priacta.comwrote:
OK everyone, it seems that some people have forgotten or missed
the
original agreement that this thread started with. There is a
communication
disconnect ("strict typing" means horribly different things to
different people right now). Please read through and understand the
following terminology before continuing to post on this thread.
We've agreed to the following terms:
- "Strict Typing" means the super strict old C style typing with
no
implicit conversions. (If you really think this is what you want,
you
are
probably mistaken. Look through prior discussions on this topic.
This
fails
for numerous reasons, including the fact that almost every input to
PHP
is
a string.)- "Weak Typing" means types in the same sense that the PHP
documentation
uses types (for example, the docs indicate substr(string, integer),
and substr(12345, "2") == "345".) (If you think you want "strict
typing",
this
is probably what you mean.)- "No Scalar Typing" should be used to indicate the current system
(where there is no provision for hinting at scalar types.)In addition, if someone potentially new expresses support for
"Strict
Typing", please assume that they really mean weak typing unless
proven otherwise (this is by far the more likely intent.) Don't get
mean,
politely
clarify terminology so that everyone can be on the same page. If
someone still insists that they want "Strict Typing" (as defined
above), point
them
to the prior discussions on the topic which explain exactly what the
problems with this are.John Crenshaw
Priacta, Inc.--
To unsubscribe,
visit: http://www.php.net/unsub.php
From: Kris Craig [mailto:kris.craig@gmail.com]
I could setup a repo on Github for this if anyone thinks that would be helpful?
--Kris
I was figuring wiki for that information, but that would limit participants to those with editing permissions.
John Crenshaw
Priacta, Inc.
On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw johncrenshaw@priacta.comwrote:
OK everyone, it seems that some people have forgotten or missed the
original agreement that this thread started with. There is a communication
disconnect ("strict typing" means horribly different things to different
people right now). Please read through and understand the following
terminology before continuing to post on this thread. We've agreed to the
following terms:
- "Strict Typing" means the super strict old C style typing with no
implicit conversions. (If you really think this is what you want, you are
probably mistaken. Look through prior discussions on this topic. This fails
for numerous reasons, including the fact that almost every input to PHP is
a string.)
Where is the term "strict typing" coming from? I've not seen this used to
describe any type system (doesn't mean it's not been used, but I'd really
like to see the usage so I can understand the label.)
- "Weak Typing" means types in the same sense that the PHP documentation
uses types (for example, the docs indicate substr(string, integer), and
substr(12345, "2") == "345".) (If you think you want "strict typing", this
is probably what you mean.)
Doesn't weak typing mean that the language implicitly converts types for
use according to a set of rules? The opposite of this being strong typing,
which means the language does not perform implicit conversions.
- "No Scalar Typing" should be used to indicate the current system (where
there is no provision for hinting at scalar types.)
And, curious about the "No Scalar Typing"?
Sorry for the questions.
Thanks,
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
+1 what Anthony said.
I think it would be prudent, as some have already suggested, for those of
us who are interested in this topic to move it to a more discreet location
so as to reduce some of the noise all around. I'll take a look at Google
docs and see if that will suit our purposes. If anyone else has any ideas
on this, please share them! =)
--Kris
On Tue, Feb 28, 2012 at 12:18 PM, Adam Richardson simpleshot@gmail.comwrote:
On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw <johncrenshaw@priacta.com
wrote:
OK everyone, it seems that some people have forgotten or missed the
original agreement that this thread started with. There is a
communication
disconnect ("strict typing" means horribly different things to different
people right now). Please read through and understand the following
terminology before continuing to post on this thread. We've agreed to the
following terms:
- "Strict Typing" means the super strict old C style typing with no
implicit conversions. (If you really think this is what you want, you
are
probably mistaken. Look through prior discussions on this topic. This
fails
for numerous reasons, including the fact that almost every input to PHP
is
a string.)Where is the term "strict typing" coming from? I've not seen this used to
describe any type system (doesn't mean it's not been used, but I'd really
like to see the usage so I can understand the label.)
- "Weak Typing" means types in the same sense that the PHP documentation
uses types (for example, the docs indicate substr(string, integer), and
substr(12345, "2") == "345".) (If you think you want "strict typing",
this
is probably what you mean.)Doesn't weak typing mean that the language implicitly converts types for
use according to a set of rules? The opposite of this being strong typing,
which means the language does not perform implicit conversions.
- "No Scalar Typing" should be used to indicate the current system (where
there is no provision for hinting at scalar types.)And, curious about the "No Scalar Typing"?
Sorry for the questions.
Thanks,
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
From: Adam Richardson [mailto:simpleshot@gmail.com]
OK everyone, it seems that some people have forgotten or missed the original agreement that this thread started with. There is a communication disconnect ("strict typing" means horribly different things to different people right now). Please read through and understand the following terminology before continuing to post on this thread. We've agreed to the following terms:
- "Strict Typing" means the super strict old C style typing with no implicit conversions. (If you really think this is what you want, you are probably mistaken. Look through prior discussions on this topic. This fails for numerous reasons, including the fact that almost every input to PHP is a string.)
Where is the term "strict typing" coming from? I've not seen this used to describe any type system (doesn't mean it's not been used, but I'd really like to see the usage so I can understand the label.)
Adam, When you say you want "Strict" or "Strong" typing, this (case 1) is what the opponents of stronger typing think you are asking for, which is why I've defined it this way. There have been a tiny handful of individuals that really are asking for this, but most people don't really want this level of strictness. Also, this level of strictness is fundamentally at odds with the nature of PHP, and it's just never going to happen. The level of typing in this first case is littered with problems. I won't get into it all, but you can read prior discussions in the archives to see it. Look for the passionate arguments made by typing opponents that talk about "massive changes", "destroying the language", and "Go use JSP". Scattered in there are some occasional explanations of the actual core issues, all of which refer to this level of typing. (Incidentally, even C++ is not this strict, so this really isn't what you want, I'm sure of it. If this is what you want, then this isn't the thread for you, because this is not what will be advocated or discussed here.)
- "Weak Typing" means types in the same sense that the PHP documentation uses types (for example, the docs indicate substr(string, integer), and substr(12345, "2") == "345".) (If you think you want "strict typing", this is probably what you mean.)
Doesn't weak typing mean that the language implicitly converts types for use according to a set of rules? The opposite of this being strong typing, which means the language does not perform implicit conversions.
"Weak" here really means weaker than the "Strong" above, but stronger than "none". Right now PHP has no typing whatsoever. "weak typing" WOULD be typing, but it is flexible, optional, and aggressively uses implicit conversions. For comparison, by these definitions C++ is halfway between "weak typing" and "strong typing" (by virtue of operator overloads, overloaded functions, and cast operators.)
This "Weak typing" will give you what you want, and it can work. Most importantly, it is not the thing that goes bump in the night for most strong typing opponents, which means it is probably possible to gather sufficient support for this. This discussion is focused on developing a rock solid proposal for "weak typing".
- "No Scalar Typing" should be used to indicate the current system (where there is no provision for hinting at scalar types.)
And, curious about the "No Scalar Typing"?
This is PHP right now. The language has no provision whatsoever for scalar types. Function parameters can be hinted as an array or as a specific class/interface, but otherwise they are assumed to be absolutely anything. I know that for people with a lot of experience in a strongly typed language this sounds like what they would normally call "Weak Typing", but it's a 3rd level. "Weak Typing" under these definitions is a lot stronger than what you would call "weak", but it's much weaker than what strong typing opponents would call "strong".
It's going to take some time to get used to the semantics, but if you want any typing enhancements you're going to have to speak the language of the people you want to convince. The communication disconnect here has been sinking this proposal for a decade.
John Crenshaw
Priacta, Inc.
On Tue, Feb 28, 2012 at 3:58 PM, John Crenshaw johncrenshaw@priacta.comwrote:
From: Adam Richardson [mailto:simpleshot@gmail.com]
On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw johncrenshaw@priacta.com
wrote:****OK everyone, it seems that some people have forgotten or missed the
original agreement that this thread started with. There is a communication
disconnect ("strict typing" means horribly different things to different
people right now). Please read through and understand the following
terminology before continuing to post on this thread. We've agreed to the
following terms:
- "Strict Typing" means the super strict old C style typing with no
implicit conversions. (If you really think this is what you want, you are
probably mistaken. Look through prior discussions on this topic. This fails
for numerous reasons, including the fact that almost every input to PHP is
a string.)****
Where is the term "strict typing" coming from? I've not seen this used to
describe any type system (doesn't mean it's not been used, but I'd really
like to see the usage so I can understand the label.)****
Adam, When you say you want “Strict” or “Strong” typing, this (case 1) is
what the opponents of stronger typing think you are asking for, which is
why I’ve defined it this way. There have been a tiny handful of individuals
that really are asking for this, but most people don’t really want this
level of strictness. Also, this level of strictness is fundamentally at
odds with the nature of PHP, and it’s just never going to happen. The level
of typing in this first case is littered with problems. I won’t get into it
all, but you can read prior discussions in the archives to see it. Look for
the passionate arguments made by typing opponents that talk about “massive
changes”, “destroying the language”, and “Go use JSP”. Scattered in there
are some occasional explanations of the actual core issues, all of which
refer to this level of typing. (Incidentally, even C++ is not this strict,
so this really isn’t what you want, I’m sure of it. If this is what you
want, then this isn’t the thread for you, because this is not what
will be advocated or discussed here.)
OK, if this is the case, I'd suggest we use the words "Weak" and "Strong",
and then speak to whether a proposal seeks to strengthen or weaken the
existing type system. That way we utilize the terminology the labels that
the existing programming language discourse community uses. Those
performing research on the topics will be able to find the terms used.
http://en.wikipedia.org/wiki/Type_system
http://www.amazon.com/Programming-Language-Pragmatics-Third-Michael/dp/0123745144/
- "Weak Typing" means types in the same sense that the PHP documentation
uses types (for example, the docs indicate substr(string, integer), and
substr(12345, "2") == "345".) (If you think you want "strict typing", this
is probably what you mean.)****
Doesn't weak typing mean that the language implicitly converts types for
use according to a set of rules? The opposite of this being strong typing,
which means the language does not perform implicit conversions.****
“Weak” here really means weaker than the “Strong” above, but stronger than
“none”. Right now PHP has no typing whatsoever. “weak typing” WOULD be
typing, but it is flexible, optional, and aggressively uses implicit
conversions. For comparison, by these definitions C++ is halfway between
“weak typing” and “strong typing” (by virtue of operator overloads,
overloaded functions, and cast operators.)
I'm not sure this is the case. PHP is typically categorized as a
dynamically typed language, meaning variables don't hold types, BUT, values
do:
http://en.wikipedia.org/wiki/Type_system#Dynamic_typing
Additionally, PHP performs conversions of values implicitly in many
instances, so it's typically referred to as weakly typed (as opposed to
strongly typed, although, as you point out, there is a continuum.) Hence,
the "===" operator compares the values without performing the implicit type
conversions PHP performs on values.
http://en.wikipedia.org/wiki/Comparison_of_programming_languages#Type_systems
This “Weak typing” will give you what you want, and it can work. Most
importantly, it is not the thing that goes bump in the night for most
strong typing opponents, which means it is probably possible to gather
sufficient support for this. This discussion is focused on developing a
rock solid proposal for “weak typing”.****
- "No Scalar Typing" should be used to indicate the current system (where
there is no provision for hinting at scalar types.)****And, curious about the "No Scalar Typing"?****
This is PHP right now. The language has no provision whatsoever for scalar
types. Function parameters can be hinted as an array or as a specific
class/interface, but otherwise they are assumed to be absolutely anything.
I know that for people with a lot of experience in a strongly typed
language this sounds like what they would normally call “Weak Typing”, but
it’s a 3rd level. “Weak Typing” under these definitions is a lot stronger
than what you would call “weak”, but it’s much weaker than what strong
typing opponents would call “strong”.
It still seems that we'd be best served by referring to PHP's current type
system as dynamic (as opposed to static) and weak (as opposed to strong) so
we use terms the language design community uses. In this respect, PHP is
very similar to Javascript.
Now, speaking to what programmers can do to declare their intentions in
terms of function parameters, I see what you're talking about. Adding the
ability to declare intentions for scalar types, too, would work to
strengthen the current type system, although I believe it would still be
considered a weak type system when judged against the backdrop of the
programming language landscape. Given PHP's dynamic, weakly typed
characteristics, this is an interesting topic:
http://en.wikipedia.org/wiki/Parameter_(computer_programming)#Datatypes
It’s going to take some time to get used to the semantics, but if you want
any typing enhancements you’re going to have to speak the language of the
people you want to convince. The communication disconnect here has been
sinking this proposal for a decade.
Agreed :) Sincerely, thanks for your feedback, John.
If you take issue with any of my questions/commentary, please correct my
knowledge shortfalls. I'm researching language design as a hobby, and
working on a parser for my own language. In addition to the communication
disconnect, I'd like to make sure that those who want to keep up with this
staggering dialogue will benefit from accurate depictions/terms.
Thanks,
Adam
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
I really liked what the O'Raily wrote here:
http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html
Please note that the author was a bass player in a band wanting to
sell CDs online when the five (5) choices were the same
brick-and-mortar major label distributors who wouldn't take his CD as
he wasn't on a major label.
He examined the options, and PHP was the only one that didn't make his
head spin.
His act of creating a single page to sell his CD online went viral,
and he accidentally built a multi-million dollar company because of
that.
Since he'd never set out to make the money, just to help his friends
(and they told 2 friends, and they told 2 friends...) he always
tracked success not by not, nor gross, but by dollars paid out to
artists[1]
He eventually sold the company to a trust fund that goes to charity
when he dies, and lives very comfortably off the interest, since he
lost interest in running the company when it just got too routine.[2]
If he had seen this strict/weak/strong stuff in PHP, that online CD
store for the indie artists would probably not have existed for quite
a long time, if ever.
He's actually been online a long time, and is worth learning from,
even if he never actually became a Real Programmer (tm), in his own
words.
PS
You can find many conversations between him and me on the old, old,
old PHP list before the split of the lists into -general etc.
[1] http://www.cdbaby.com/About
[2] http://sivers.org/trust
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
I think that's a bit of a stretch, to say the least. The same argument
could be made that PHP 5's introduction of stronger OO implementation would
have scared this person away. The fact is, we don't know that either of
them would have. For one thing, I doubt he monitored the PHP Internals
list; if he had, that in and of itself would have been enough to scare him
away lol. If strict typing was the norm, then yeah it probably would have
scared him off. But adding optional typing, which is what we've been
discussing here? I seriously doubt it.
--Kris
I really liked what the O'Raily wrote here:
http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html
Please note that the author was a bass player in a band wanting to
sell CDs online when the five (5) choices were the same
brick-and-mortar major label distributors who wouldn't take his CD as
he wasn't on a major label.He examined the options, and PHP was the only one that didn't make his
head spin.His act of creating a single page to sell his CD online went viral,
and he accidentally built a multi-million dollar company because of
that.Since he'd never set out to make the money, just to help his friends
(and they told 2 friends, and they told 2 friends...) he always
tracked success not by not, nor gross, but by dollars paid out to
artists[1]He eventually sold the company to a trust fund that goes to charity
when he dies, and lives very comfortably off the interest, since he
lost interest in running the company when it just got too routine.[2]If he had seen this strict/weak/strong stuff in PHP, that online CD
store for the indie artists would probably not have existed for quite
a long time, if ever.He's actually been online a long time, and is worth learning from,
even if he never actually became a Real Programmer (tm), in his own
words.PS
You can find many conversations between him and me on the old, old,
old PHP list before the split of the lists into -general etc.[1] http://www.cdbaby.com/About
[2] http://sivers.org/trust--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
I don't think the strong/weak stuff is necessary at all. Either a
programmer cares about datatype or they don't and the vast, vast
majority won't.
Declaring a variable's datatype should have the effect of locking that
variable's datatype down and not allowing it to switch types with the
sole exception of NULL.
Trying to declare a degree of strength to the typing is severe
overkill. I recognize that I suggested this in my first proposal, but
at this point I'm opposed to it.
I think that's a bit of a stretch, to say the least. The same argument
could be made that PHP 5's introduction of stronger OO implementation would
have scared this person away. The fact is, we don't know that either of
them would have. For one thing, I doubt he monitored the PHP Internals
list; if he had, that in and of itself would have been enough to scare him
away lol. If strict typing was the norm, then yeah it probably would have
scared him off. But adding optional typing, which is what we've been
discussing here? I seriously doubt it.--Kris
I really liked what the O'Raily wrote here:
http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html
Please note that the author was a bass player in a band wanting to
sell CDs online when the five (5) choices were the same
brick-and-mortar major label distributors who wouldn't take his CD as
he wasn't on a major label.He examined the options, and PHP was the only one that didn't make his
head spin.His act of creating a single page to sell his CD online went viral,
and he accidentally built a multi-million dollar company because of
that.Since he'd never set out to make the money, just to help his friends
(and they told 2 friends, and they told 2 friends...) he always
tracked success not by not, nor gross, but by dollars paid out to
artists[1]He eventually sold the company to a trust fund that goes to charity
when he dies, and lives very comfortably off the interest, since he
lost interest in running the company when it just got too routine.[2]If he had seen this strict/weak/strong stuff in PHP, that online CD
store for the indie artists would probably not have existed for quite
a long time, if ever.He's actually been online a long time, and is worth learning from,
even if he never actually became a Real Programmer (tm), in his own
words.PS
You can find many conversations between him and me on the old, old,
old PHP list before the split of the lists into -general etc.[1] http://www.cdbaby.com/About
[2] http://sivers.org/trust--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
I can honestly see a use for it, much as there's a use for having both
"include" and "require". It may not be a critical distinction, but it
sounds like some people at least would enjoy the added flexibility.
If we did only go with one, I would want it to be the "strong" one. But
again, I think both is the best approach as it helps to bridge many of
these diverging viewpoints on the subject.
--Kris
On Tue, Feb 28, 2012 at 2:48 PM, Michael Morris dmgx.michael@gmail.comwrote:
I don't think the strong/weak stuff is necessary at all. Either a
programmer cares about datatype or they don't and the vast, vast
majority won't.Declaring a variable's datatype should have the effect of locking that
variable's datatype down and not allowing it to switch types with the
sole exception of NULL.Trying to declare a degree of strength to the typing is severe
overkill. I recognize that I suggested this in my first proposal, but
at this point I'm opposed to it.I think that's a bit of a stretch, to say the least. The same argument
could be made that PHP 5's introduction of stronger OO implementation
would
have scared this person away. The fact is, we don't know that either of
them would have. For one thing, I doubt he monitored the PHP Internals
list; if he had, that in and of itself would have been enough to scare
him
away lol. If strict typing was the norm, then yeah it probably would
have
scared him off. But adding optional typing, which is what we've been
discussing here? I seriously doubt it.--Kris
I really liked what the O'Raily wrote here:
http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html
Please note that the author was a bass player in a band wanting to
sell CDs online when the five (5) choices were the same
brick-and-mortar major label distributors who wouldn't take his CD as
he wasn't on a major label.He examined the options, and PHP was the only one that didn't make his
head spin.His act of creating a single page to sell his CD online went viral,
and he accidentally built a multi-million dollar company because of
that.Since he'd never set out to make the money, just to help his friends
(and they told 2 friends, and they told 2 friends...) he always
tracked success not by not, nor gross, but by dollars paid out to
artists[1]He eventually sold the company to a trust fund that goes to charity
when he dies, and lives very comfortably off the interest, since he
lost interest in running the company when it just got too routine.[2]If he had seen this strict/weak/strong stuff in PHP, that online CD
store for the indie artists would probably not have existed for quite
a long time, if ever.He's actually been online a long time, and is worth learning from,
even if he never actually became a Real Programmer (tm), in his own
words.PS
You can find many conversations between him and me on the old, old,
old PHP list before the split of the lists into -general etc.[1] http://www.cdbaby.com/About
[2] http://sivers.org/trust--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
Both of these must be
declared formally (otherwise PHP assumes scalar)
I believe you mean "dynamic" or "loose" datatyping.
Scalar would imply that you couldn't do this:
array $a = array(); //force $a to always be array, and never anything
else
object $o = new Object(); //ditto, only object
// A tolerant variable.
integer $a = 3;// A strict variable
strict integer $b = 2;Tolerant variables silently cast values to their declared datatype.
Maybe they should raise E_NOTICE?
Raising E_NOTICE is a backwards compatible "break" of little added value.
Programmers who want their variables strongly typed will use strict,
those who don't won't.
A proposal that includes an explicit "loose" or "dynamic", which means
the default behavior, but is self-documenting as intentional
loose-ness would be a better idea, imho.
The idea is sound, though I daresay the actual implementation may be
problematic to the point of "impossible".
PRESUMPTION:
ANY strict datatype could also be NULL, to represent a failure
condition...
Otherwise, when you are out of RAM:
strict $o = new Object(); //violates strict, because Object HAS to be
NULL, as there is no RAM left for it to be an object.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
PRESUMPTION:
ANY strict datatype could also be NULL, to represent a failure
condition...Otherwise, when you are out of RAM:
strict $o = new Object(); //violates strict, because Object HAS to be
NULL, as there is no RAM left for it to be an object.
Uh? No. You would get a fatal error because PHP exceeded maximum
allowed memory.