Hi, all
Today I read a post around that:
http://nikic.github.com/2012/03/06/Scalar-type-hinting-is-harder-than-you-think
As some of us are leading to the 3rd and some to the 4th or other ways
described in here (I think we can simply exclude the first one ...)
Would it be an option (to get this moved forward) to let people vote
which way they like most (or which comes closest to their
best-solution)?
I pretty much like the 3rd way ... the only thing I see that has not
been discussed enough is how to handle integers on 64bit and 32bit
installations.
Bye
Simon
tl;dr: "strict type hinting" and "Boxing based type hinting" (the second
one with some changes).
Just read through it, and I was unaware there's still ideas to continue
working on type hinting in PHP.
That's good news, at least for me :)
I'm just lurking around here, but if my thoughts can help, here they are.
Here's a short mapping of considerations related to the various
implementations exposed on that blog post:
- Strict type hinting (also aliased by me "YES please, yes!"):
- It enforces the developer to keep his code cleaner
- It helps framework devs in reducing the overhead caused by casting
within internal classes - Unsure devs can always call
foo((int) $bar);if they are unsure
of what their code produces. The loss of performance will be only because
of crap code. - Documentation of return values will become somehow a must
- Throwing exceptions, yes please... Unsure what level anyway... I
like the E_CATCHABLE_FATAL way. That gives enough flexibility...
Unenforced type hinting:
- If you have mixed types, then you just don't need type hinting. Lazy
devs can still avoid using it. Lazyness shouldn't really be
encouraged, so
providing some kind of "backwards compatibility" just makes the feature
useless :\- This is not a feature, it's just better implicit documentation for
methods
- This is not a feature, it's just better implicit documentation for
- Casting weak type hinting:
- This is just case (1) with implicit casting. In my opinion, developers
should do the casts themselves withfoo((int) $bar).- Implicit casting in method calls would lead to chaos in tracking
bugs (for me). Not to mention warnings in N-level hierarchies
where values
are pushed forward and backward. Let's throw the exception before it
becomes chaos! - I am unsure if it also would degrade performance, but I know very
little of internals.
- Implicit casting in method calls would lead to chaos in tracking
- Strict weak type hinting:
I don't really see allowing any of [int, string, float] for any type
hint for int, string or float as a feature. That's a silent failure to my
eyes. An alternative could be throwing warnings if there's a type mismatch,
otherwise the feature doesn't (again) provide anything new to me... It
probably just makes it messier. - Boxing based type hinting:
This is unrealted to the other 4 points to me. What PHP could probably
do for us is to cast an object to a scalar when the object implements the
compatible magic method (like__toString).
Anyway,__toScalar()and__fromScalar($scalar)feels weak. I'd
prefer a strict, well defined list of possible magic methods for the
various internal types. Would that be a big performance issue?
Marco Pivetta
Hi, all
Today I read a post around that:
http://nikic.github.com/2012/03/06/Scalar-type-hinting-is-harder-than-you-think
As some of us are leading to the 3rd and some to the 4th or other ways
described in here (I think we can simply exclude the first one ...)
Would it be an option (to get this moved forward) to let people vote
which way they like most (or which comes closest to their
best-solution)?I pretty much like the 3rd way ... the only thing I see that has not
been discussed enough is how to handle integers on 64bit and 32bit
installations.Bye
Simon
Unenforced type hinting:
- If you have mixed types, then you just don't need type hinting. Lazy
devs can still avoid using it. Lazyness shouldn't really be
encouraged, so
providing some kind of "backwards compatibility" just makes the
feature
useless :\
- This is not a feature, it's just better implicit documentation for
methods
I just want to quick point out that I suggested the idea of introducing a
scalar type hint that would accept all scalars but would disallow passing
in arrays or objects. Additionally, the proposal outlined the option of
introducing aliases for the scalar hint (bool, int, float, string) which
would help developers better declare their intentions in terms of how they
expected to use the scalar type.
I don't think Nikita was referring to my idea when he referenced
"unenforced type hinting", as his examples show that passing in an object
or array would both succeed even with an int (scalar) type hint. That said,
I couldn't find a proposal suggesting a type hinting proposal that was
purely documentational, so I wanted to take the time to make sure there was
no miscommunication.
Adam
From: Marco Pivetta [mailto:ocramius@gmail.com]
tl;dr: "strict type hinting" and "Boxing based type hinting" (the second one with some changes).
Just read through it, and I was unaware there's still ideas to continue working on type hinting in PHP.
There's been some recent discussion facilitated by understanding past fears and embracing some foundation principles as requirements of a successful solution (which solves a major problem with the scalar typing discussions from the past.)
That's good news, at least for me :)
I'm just lurking around here, but if my thoughts can help, here they are.Here's a short mapping of considerations related to the various implementations exposed on that blog post:
- Strict type hinting (also aliased by me "YES please, yes!"):
If you want scalar typing you'll have to move past this. I go into this a little below, but you should also look through the arguments in the archives. This is too strict (more strict that C++ actually). There are some rock solid arguments that have basically shut the door on this one forever. It will never pass a vote.
2. Unenforced type hinting:
This almost happened in 5.4, but eventually got pulled. More interestingly, the community rejected it because it is useless. See the comments at http://sebastian-bergmann.de/archives/900-Scalar-Type-Hints-in-PHP-5.3.99.html for a good picture of why people hated this idea. Previous discussions on this mailing list also point out that this idea would ultimately be a dead end (a very good catch by...someone...).
- Casting weak type hinting:
Silently casting and discarding lost data is a huge problem and ultimately doesn't offer any substantial benefit. This was discussed previously. Also creates a dead end.
- Strict weak type hinting:
This realm is the most likely to succeed because the core already does something like this for internal functions (via zend_parse_parameters). This balances utility (enforcing the type) with fundamental language design principles (juggling). You need to understand the fundamental language principles to understand why any solution MUST lie somewhere in this realm. Remember that:
1.2 === "12";
"2"+"2" === 4;
substr(12345, "2") === "345";
This type juggling affects the language in all sorts of ways. For example, PHP uses '.' for concatenation (not '+' like most similar languages) which ensures that there is no ambiguity as to whether you are operating against the integer value or the string value. PHP is designed so that you generally don't have to care whether a value is ACTUALLY an integer or a string internally, it will be treated as whatever type you use it as. In PHP int(2), float(2.0), and string("2") can generally be used completely interchangeably with no variation in results whatsoever. When core devs say that "strict typing would make it not PHP anymore", this is what they mean; it would badly violate this core concept. If you want scalar typing, you need a solution that embraces this fundamental design principle.
- Boxing based type hinting:
This is a hack that's been proposed before, but you don't need to look very far to see why this ultimately breaks down badly. Even aggressive casting additions to the language would not make this work particularly well. Anyone who's ever tried to create a class wrapper for a scalar in C++ (which probably includes the core devs) is not likely to be down with this idea.
John Crenshaw
Priacta, Inc.
Thank you for clarifying some things :)
- Strict weak type hinting:
This realm is the most likely to succeed because the core already does
something like this for internal functions (via zend_parse_parameters).
This balances utility (enforcing the type) with fundamental language design
principles (juggling). You need to understand the fundamental language
principles to understand why any solution MUST lie somewhere in this realm.
Remember that:
1.2 === "12";
"2"+"2" === 4;
substr(12345, "2") === "345";This type juggling affects the language in all sorts of ways. For example,
PHP uses '.' for concatenation (not '+' like most similar languages) which
ensures that there is no ambiguity as to whether you are operating against
the integer value or the string value. PHP is designed so that you
generally don't have to care whether a value is ACTUALLY an integer or a
string internally, it will be treated as whatever type you use it as. In
PHP int(2), float(2.0), and string("2") can generally be used completely
interchangeably with no variation in results whatsoever. When core devs say
that "strict typing would make it not PHP anymore", this is what they mean;
it would badly violate this core concept. If you want scalar typing, you
need a solution that embraces this fundamental design principle.
Yeah, I don't want to start a discussion on that now nor start a (probably
already repeated) war on it, but I think those principles are dead since
very long time...
- Boxing based type hinting:
This is a hack that's been proposed before, but you don't need to look
very far to see why this ultimately breaks down badly. Even aggressive
casting additions to the language would not make this work particularly
well. Anyone who's ever tried to create a class wrapper for a scalar in C++
(which probably includes the core devs) is not likely to be down with this
idea.
That's not about working with scalar wrappers (which, anyway, would be very
useful in Doctrine). It is about casting any object to array... ((int) $dbTableGateway) could implicitly cause an sql COUNT query and stuff
like that :) Maybe I'm too java-ish, but those look like good improvements
to me :)
Thank you for clarifying some things :)
4. Strict weak type hinting:This realm is the most likely to succeed because the core already does
something like this for internal functions (via zend_parse_parameters).
This balances utility (enforcing the type) with fundamental language design
principles (juggling). You need to understand the fundamental language
principles to understand why any solution MUST lie somewhere in this realm.
Remember that:
1.2 === "12";
"2"+"2" === 4;
substr(12345, "2") === "345";This type juggling affects the language in all sorts of ways. For example,
PHP uses '.' for concatenation (not '+' like most similar languages) which
ensures that there is no ambiguity as to whether you are operating against
the integer value or the string value. PHP is designed so that you
generally don't have to care whether a value is ACTUALLY an integer or a
string internally, it will be treated as whatever type you use it as. In
PHP int(2), float(2.0), and string("2") can generally be used completely
interchangeably with no variation in results whatsoever. When core devs say
that "strict typing would make it not PHP anymore", this is what they mean;
it would badly violate this core concept. If you want scalar typing, you
need a solution that embraces this fundamental design principle.Yeah, I don't want to start a discussion on that now nor start a (probably
already repeated) war on it, but I think those principles are dead since
very long time...
If you think that the essential core functionality of type juggling is
"dead since very long time" you have no business making decisions on the
future of PHP. PHP without type juggling is no longer PHP!
Call my opinion extreme if you wish, but I believe Rasmus, the owner of
the trademark on PHP, has suggested that he would not allow the name PHP
to be used if it is removed.
If you really, really want strong type in a PHP like language, please
fork it, rename it, and go away! See if the market follows you or PHP.
2012/3/18 John Crenshaw johncrenshaw@priacta.com:
2. Unenforced type hinting:
This almost happened in 5.4, but eventually got pulled. More interestingly, the community rejected it because it is useless. See the comments at http://sebastian-bergmann.de/archives/900-Scalar-Type-Hints-in-PHP-5.3.99.html for a good picture of why people hated this idea. Previous discussions on this mailing list also point out that this idea would ultimately be a dead end (a very good catch by...someone...).
Hi, John
Thanks for clarifying that way.
I understand why some people want to have that ... to please really
all people ... make a solution that fits for EVERYONE.
But that would (on the other hand) cause way more confusion if you're
working with different projects (using Sebastian Bergmanns example)
... one implementing this the way we would implement "Strict type
hinting" - because that's what he wants ... and another one is
implementing it as "Casting weak type hinting" ... and so on.
I know that the user still has to add some code, but I don't like the
fact to have additional type-hinting that's just doing nothing - and
the user is then adding it if he wants.
I'm still for the 3rd solution as it is most likely the current
type-hint and is not that strict as the first solution. Just to have
it consistent.
What I like most here: All parameters that can be converted to the
wanted format without loosing something are accepted, all other will
stop the execution of the script.
Bye
Simon
2012/3/18 Simon Schick simonsimcity@googlemail.com:
2012/3/18 John Crenshaw johncrenshaw@priacta.com:
2. Unenforced type hinting:
This almost happened in 5.4, but eventually got pulled. More interestingly, the community rejected it because it is useless. See the comments at http://sebastian-bergmann.de/archives/900-Scalar-Type-Hints-in-PHP-5.3.99.html for a good picture of why people hated this idea. Previous discussions on this mailing list also point out that this idea would ultimately be a dead end (a very good catch by...someone...).
Hi, John
Thanks for clarifying that way.
I understand why some people want to have that ... to please really
all people ... make a solution that fits for EVERYONE.But that would (on the other hand) cause way more confusion if you're
working with different projects (using Sebastian Bergmanns example)
... one implementing this the way we would implement "Strict type
hinting" - because that's what he wants ... and another one is
implementing it as "Casting weak type hinting" ... and so on.I know that the user still has to add some code, but I don't like the
fact to have additional type-hinting that's just doing nothing - and
the user is then adding it if he wants.I'm still for the 3rd solution as it is most likely the current
type-hint and is not that strict as the first solution. Just to have
it consistent.
What I like most here: All parameters that can be converted to the
wanted format without loosing something are accepted, all other will
stop the execution of the script.Bye
Simon
Hi, All
Just to add an example why I want a more strictly type-check here as
we have in the current type-juggling:
http://www.brandonsavage.net/an-xss-vulerability-in-the-making/?utm_source=rss&utm_medium=rss&utm_campaign=an-xss-vulerability-in-the-making
Bye
Simon
On Sun, Mar 18, 2012 at 7:12 AM, Simon Schick
simonsimcity@googlemail.comwrote:
Hi, All
Just to add an example why I want a more strictly type-check here as
we have in the current type-juggling:
I see the example given as one of poor validation, not a reason for more
strict type checking in a dynamic, weakly typed language.
One could:
- use a regex
- setting the third argument (strict comparison) of
in_array()to true -OR-
looping through the array and checking equivalence with === - ensure the type juggled value (the integer form) was returned and used
rather than using the original string
I actually like the conversation on scalar type hinting, and I've even
offered some ideas for integrating a form of it, too. However, poor input
validation is not one of the reasons that I would use to justify its
inclusion. The goal of proper input validation should be to account for
page requests that include invalid data and provide appropriate feedback
within the natural flow of the application. Erring out when calling a more
strongly typed function at runtime does not provide this type of
application flow.
Adam
2012/3/18 Adam Jon Richardson adamjonr@gmail.com:
On Sun, Mar 18, 2012 at 7:12 AM, Simon Schick
simonsimcity@googlemail.comwrote:Hi, All
Just to add an example why I want a more strictly type-check here as
we have in the current type-juggling:I see the example given as one of poor validation, not a reason for more
strict type checking in a dynamic, weakly typed language.One could:
- use a regex
- setting the third argument (strict comparison) of
in_array()to true -OR-
looping through the array and checking equivalence with ===- ensure the type juggled value (the integer form) was returned and used
rather than using the original stringI actually like the conversation on scalar type hinting, and I've even
offered some ideas for integrating a form of it, too. However, poor input
validation is not one of the reasons that I would use to justify its
inclusion. The goal of proper input validation should be to account for
page requests that include invalid data and provide appropriate feedback
within the natural flow of the application. Erring out when calling a more
strongly typed function at runtime does not provide this type of
application flow.Adam
Hi, Adam
I totally agree that type-hinting should not cover what the programmer
should do for validating the given input ...
But I just wanted to point out that this is something the author (and
I) would never expect to happen ...
in_array("123abc", array(3, 7, 123, 28)) === true
But that's another thing :)
I just wanted to point out that I don't want to have the string
"123abc" accepted as an integer :)
Anyways ... This thread should be a discussion about the whole
concept, not the details.
Sorry for getting off-context here.
Bye
Simon
On Sun, Mar 18, 2012 at 7:11 PM, Simon Schick
simonsimcity@googlemail.comwrote:
Hi, Adam
I totally agree that type-hinting should not cover what the programmer
should do for validating the given input ...
But I just wanted to point out that this is something the author (and
I) would never expect to happen ...in_array("123abc", array(3, 7, 123, 28)) === true
Hi Simon,
That's how we differ in terms of perspective. When I see that in_array()
accepts a third argument $strict and that $strict defaults to false,
in_array("123abc", array(3, 7, 123)) === true is the behavior I expect for
that function:
http://php.net/manual/en/function.in-array.php
That said, perhaps the documentation could be augmented to help clarify the
issue. While example 2 on that page illustrates a non-match using the
strict check, it does seem like showing the opposite (a surprising match
when $strict is false, such as in the example your link pointed to) would
also prove beneficial to users, too.
Nice commentary.
Adam
But I just wanted to point out that this is something the author
(and I) would never expect to happen ...
in_array("123abc", array(3, 7, 123, 28)) === true
Well, would you never expect
select ( '123abc' in (3,7,123,28) )
to return boolean true in SQL?
Because it does.
Me, I'm happy with the parity of these two languages that so often
must work in tandem. YMMV but I don't see anything kooky. As Adam &
others have pointed out, the author of that blog post used the
original input as-is. Akin to passing a var into a sanitization
function (by value), getting a return true, and continuing processing
w/the initial var. I'm not saying I haven't done plenty of similarly
stupid things, but I don't see them as evidence to be entered against,
well, anything except my own incompetence.
-- S.
Hello Simon,
in_array("123abc", array(3, 7, 123, 28)) === true
This is a pointless example, because the first argument of in_array is of
type "mixed" and not "int". So, this may cause many headaches, but it is
irrelevant to the discussion about scalar type hints.
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/19 Simon Schick simonsimcity@googlemail.com
2012/3/18 Adam Jon Richardson adamjonr@gmail.com:
On Sun, Mar 18, 2012 at 7:12 AM, Simon Schick
simonsimcity@googlemail.comwrote:Hi, All
Just to add an example why I want a more strictly type-check here as
we have in the current type-juggling:I see the example given as one of poor validation, not a reason for more
strict type checking in a dynamic, weakly typed language.One could:
- use a regex
- setting the third argument (strict comparison) of
in_array()to true
-OR-
looping through the array and checking equivalence with ===- ensure the type juggled value (the integer form) was returned and used
rather than using the original stringI actually like the conversation on scalar type hinting, and I've even
offered some ideas for integrating a form of it, too. However, poor input
validation is not one of the reasons that I would use to justify its
inclusion. The goal of proper input validation should be to account for
page requests that include invalid data and provide appropriate feedback
within the natural flow of the application. Erring out when calling a
more
strongly typed function at runtime does not provide this type of
application flow.Adam
Hi, Adam
I totally agree that type-hinting should not cover what the programmer
should do for validating the given input ...
But I just wanted to point out that this is something the author (and
I) would never expect to happen ...in_array("123abc", array(3, 7, 123, 28)) === true
But that's another thing :)
I just wanted to point out that I don't want to have the string
"123abc" accepted as an integer :)Anyways ... This thread should be a discussion about the whole
concept, not the details.
Sorry for getting off-context here.Bye
Simon