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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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:

1. 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...
2.

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
3. Casting weak type hinting:
- This is just case (1) with implicit casting. In my opinion, developers
should do the casts themselves with `foo((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.
4. 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.
5. 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

http://twitter.com/Ocramius

http://marco-pivetta.com



On 17 March 2012 14:38, Simon Schick <[email protected]> wrote:

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

On Sat, Mar 17, 2012 at 10:37 AM, Marco Pivetta <[email protected]> wrote:

> 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:[email protected]]
>
> 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:
>
> 1. 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...).

> 3. 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.

> 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.

> 5. 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 :)


> 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...


> > 5. 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 :)

2012/3/18 John Crenshaw <[email protected]>:
>
>>       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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 3/17/2012 11:46 PM, Marco Pivetta wrote:
> 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.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

2012/3/18 Simon Schick <[email protected]>:
> 2012/3/18 John Crenshaw <[email protected]>:
>>
>>>       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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Sun, Mar 18, 2012 at 7:12 AM, Simon Schick
<[email protected]>wrote:

>
> 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


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 <[email protected]>:
> On Sun, Mar 18, 2012 at 7:12 AM, Simon Schick
> <[email protected]>wrote:
>
>>
>> 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
>
>
> 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

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Sun, Mar 18, 2012 at 7:11 PM, Simon Schick
<[email protected]>wrote:

> 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.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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 <[email protected]>

> 2012/3/18 Adam Jon Richardson <[email protected]>:
> > On Sun, Mar 18, 2012 at 7:12 AM, Simon Schick
> > <[email protected]>wrote:
> >
> >>
> >> 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
> >
> >
> > 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
>
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>