subject:"RE\: \[PHP\-DEV\] \[RFC\] Scalar Type Hinting With Casts \(re\-opening\)"

hi Andrea,

On Sun, Jul 13, 2014 at 3:57 AM, Andrea Faulds a...@ajf.me wrote:
 Good evening,

 PHP’s type hinting system is rather incomplete as it does not support 
 scalars, only arrays, callables and objects. In 2012, Anthony Ferrara created 
 an RFC which proposed type hinting for scalar types (int, float, bool, string 
 and resource) with casting, with behaviour nearly the same as that of 
 zend_parse_parameters. Sadly, he later left PHP internals and withdrew his 
 RFCs.

 Since I am very much in favour of scalar type hints, I’ve updated the patch 
 to master and made some minor improvements, and I am re-opening the RFC with 
 the intent to try and get it into PHP 5.7. The patch is mostly there. It 
 needs some more tests and there are some edge cases I need to deal with, but 
 it otherwise works, and I expect I can finish fixing it up very soon.

 The RFC is here: https://wiki.php.net/rfc/scalar_type_hinting_with_cast

 A pull request is here: https://github.com/php/php-src/pull/717

 I’m hoping I can get this into PHP 5.7. I think scalar type hinting would be 
 a valuable addition to PHP’s existing type hinting system.

very nice work, thanks!

Some comments or wishes. I know these points have been discussed
already in the other threads but I still think it is worth posting
that here and (re) consider it.

To me argument types handling should match what we already do for
classes, strict handling. I asked many users at various conferences or
large companies using PHP and this is also what they wish. Indeed I am
not saying that all users wish that (who am I to say that? :) but I
feel like there is a large majority expecting this behavior.

The argument saying that it is not the PHP way is somehow incorrect
here, given that we already do that for classe. The type jungling
makes sense in implementations, as it always was but argument passing
and validation have been a source of pain since very long. I could
imagine one exception with the numeric type, which could accept
anything and got converted to integer/numeric values, like 1235ab or
other weird things.


Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-24 Thread Patrick Schaaf

 The argument saying that it is not the PHP way is somehow incorrect
 here, given that we already do that for classe. The type jungling
 makes sense in implementations, as it always was but argument 
passing
 and validation have been a source of pain since very long. I could
 imagine one exception with the numeric type, which could accept
 anything and got converted to integer/numeric values, like 1235ab or
 other weird things.

Personal opinion of a nonvoter, just for the record :)

The fact that roughly everybody in the strict-and-validation camp in the 
recent discussions, adds in a different view on with the exception of, 
very very strongly suggests that the strict-and-validation POV is wrong 
wrong wrong.

On the one hand, because calling code will become sprinkled with 
casts on function calls to coerce the arguments to conform to the strict 
interpretation.

And on the other hand, because validation needs, for all practical 
purposes, are far more finegrained than any half-a-dozen-type scheme.

So, I'm 100% in the cast camp, i.e. interpret scalar type annotation of 
function arguments as syntactic sugar for explicit casts at the beginning 
of the function.

best regards
  Patrick

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

On Jul 24, 2014 10:34 AM, Patrick Schaaf p...@bof.de wrote:

  The argument saying that it is not the PHP way is somehow incorrect

  here, given that we already do that for classe. The type jungling

  makes sense in implementations, as it always was but argument passing

  and validation have been a source of pain since very long. I could

  imagine one exception with the numeric type, which could accept

  anything and got converted to integer/numeric values, like 1235ab or

  other weird things.



 Personal opinion of a nonvoter, just for the record :)



 The fact that roughly everybody in the strict-and-validation camp in the
recent discussions, adds in a different view on with the exception of,
very very strongly suggests that the strict-and-validation POV is wrong
wrong wrong.


I wrote I could imagine not I want or prefer the numeric one. To me
being strict is what I would like to see.

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-24 Thread Patrick Schaaf

Hi,

there is, it seems, something missing from both the RFC and the 
discussion, as far as I read it. Sorry if it came up before, it was a huge 
amount of mails...

How does the proposal affect method compatibility between 
subclasses and baseclasses? Will two methods there, differing in the 
scalar type annotations of one of their arguments, elicit STRICT 
warnings, like object type annotations do?

I'm undecided about what would be the right thing in that regard, but I 
think it should be clarified.

best regards
  Patrick

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

On Thu, Jul 24, 2014 at 10:42 AM, Patrick Schaaf p...@bof.de wrote:
 Hi,

 there is, it seems, something missing from both the RFC and the
 discussion, as far as I read it. Sorry if it came up before, it was a huge
 amount of mails...

 How does the proposal affect method compatibility between
 subclasses and baseclasses? Will two methods there, differing in the
 scalar type annotations of one of their arguments, elicit STRICT
 warnings, like object type annotations do?

I think it should behave like class arguments do.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-24 Thread Stas Malyshev

Hi!

 I think it should behave like class arguments do.

That's called strict typing and was discussed many times. Do we really
want another round of repeating the same arguments?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

On Thu, Jul 24, 2014 at 10:52 AM, Pierre Joye pierre@gmail.com wrote:
 On Thu, Jul 24, 2014 at 10:42 AM, Patrick Schaaf p...@bof.de wrote:
 Hi,

 there is, it seems, something missing from both the RFC and the
 discussion, as far as I read it. Sorry if it came up before, it was a huge
 amount of mails...

 How does the proposal affect method compatibility between
 subclasses and baseclasses? Will two methods there, differing in the
 scalar type annotations of one of their arguments, elicit STRICT
 warnings, like object type annotations do?

 I think it should behave like class arguments do.

I should be more precise :)

say:

function i(integer $i)
function f(float $f)
function s(string $s)

$i = 12;
$f  = 1.234;
$s = abcdef;

For integer arguments:

Works:
i($i);

Fails:
i($f);
i($s);
i(new StdClass);

float fails as the argument cannot be an integer without lost of
information. It is a mis-usage of this function argument and the
intend of the caller can only be guessed and can only lead to bugs.

For float:
Works:
f($i);
f($f);
integer is, if I take the class behavior as example, like a float,
same interface, fully compatible.

Fails:
f($s);
i(new StdClass);

For string, every scalar should work as both float and integer are
easily converted to string, we can compare them to objects with a
__toString method. I could live with strict too here but implicit
string conversion makes sense here. Float precision setting is used
for the decimal precision.

Arrays and objects without __toString fails, obvioulsy.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

On Thu, Jul 24, 2014 at 11:03 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
 Hi!

 I think it should behave like class arguments do.

 That's called strict typing and was discussed many times. Do we really
 want another round of repeating the same arguments?

As I said, yes it was discussed, and yes I think it makes sense to
consider it. I won't discuss or battle that to hell tho', it is only
the way it my humble opinion.


-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

On Thu, Jul 24, 2014 at 11:03 AM, Pierre Joye pierre@gmail.com wrote:
 On Thu, Jul 24, 2014 at 10:52 AM, Pierre Joye pierre@gmail.com wrote:
 On Thu, Jul 24, 2014 at 10:42 AM, Patrick Schaaf p...@bof.de wrote:
 Hi,

 there is, it seems, something missing from both the RFC and the
 discussion, as far as I read it. Sorry if it came up before, it was a huge
 amount of mails...

 How does the proposal affect method compatibility between
 subclasses and baseclasses? Will two methods there, differing in the
 scalar type annotations of one of their arguments, elicit STRICT
 warnings, like object type annotations do?

 I think it should behave like class arguments do.

 I should be more precise :)

 say:

 function i(integer $i)
 function f(float $f)
 function s(string $s)

 $i = 12;
 $f  = 1.234;
 $s = abcdef;

 For integer arguments:

 Works:
 i($i);

 Fails:
 i($f);
 i($s);
 i(new StdClass);

 float fails as the argument cannot be an integer without lost of
 information. It is a mis-usage of this function argument and the
 intend of the caller can only be guessed and can only lead to bugs.

 For float:
 Works:
 f($i);
 f($f);
 integer is, if I take the class behavior as example, like a float,
 same interface, fully compatible.

 Fails:
 f($s);
 i(new StdClass);

 For string, every scalar should work as both float and integer are
 easily converted to string, we can compare them to objects with a
 __toString method. I could live with strict too here but implicit
 string conversion makes sense here. Float precision setting is used
 for the decimal precision.

 Arrays and objects without __toString fails, obvioulsy.

and to clarify this, after I got some questions/comments on irc etc.:

f.e.
foo(int $a) {
var_dump($a===123);
}

foo(123)  true
foo(123)  true
foo(123a) error, bad arg

same for float. The cast happens, it would not make sense if not :)

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-24 Thread Zeev Suraski

 -Original Message-
 From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
 Sent: Thursday, July 24, 2014 12:04 PM
 To: Pierre Joye
 Cc: PHP internals
 Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

 That's called strict typing and was discussed many times. Do we really
 want
 another round of repeating the same arguments?

We definitely do not..

To elaborate, the notion that we already have strict class types for
classes, so we should have the same thing for scalar makes no sense at all.
Here's why:

1. If it was the case, we'd add this right when we added class type hints
(strict class types).
2. The fact of the matter is that we did not.  Why not?  Because scalars in
PHP behave in an inherently different way.
3. As I stated already, 'Dynamic Typing defines PHP, class type hints do
not'.  Class type hints were added at a *MUCH* later stage, as a part of the
major rollout of the new object model of PHP 5.  It was actually agreed that
the *only* way we'd add such type hints is if we weren't going to have them
for scalar types.

What we have on the table right now - casting type hints - can be made to
behave in a way that's consistent with the dynamic typing nature of PHP.

My main concern about the RFC the way it stands right now is that the
current direction involves E_RECOVERABLE_ERROR instead of E_STRICT or E_CAST
for data loss.  This results in both consistency issues with casting as well
as incompatibility with the dynamic nature of PHP scalars.  I know the RFC
author (Andrea) disagrees with me about it, but I think we need to find a
way to put this into a much wider decision.  Probably the most practical
thing to do is to put it as a secondary question in the RFC, although those
can be tricky.

Zeev

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

On Thu, Jul 24, 2014 at 12:25 PM, Zeev Suraski z...@zend.com wrote:

 We definitely do not..

Well, open list, if some like to discuss it, we can. But see below, it
may not be necessary.

 To elaborate, the notion that we already have strict class types for
 classes, so we should have the same thing for scalar makes no sense at all.
 Here's why:

 1. If it was the case, we'd add this right when we added class type hints
 (strict class types).

Just like we'd to add full OO concepts right with 5.0.

 3. As I stated already, 'Dynamic Typing defines PHP, class type hints do
 not'.  Class type hints were added at a *MUCH* later stage, as a part of the
 major rollout of the new object model of PHP 5.  It was actually agreed that
 the *only* way we'd add such type hints is if we weren't going to have them
 for scalar types.

 What we have on the table right now - casting type hints - can be made to
 behave in a way that's consistent with the dynamic typing nature of PHP.

Except for the cases I listed in my 2nd mail, which you certainly did
not read. However, my mistake, I had an outdated version of the RFC
and clearing my local cache shows me the actual one, which matches
100% what I would like to see and wrote in my replies in this thread.

 My main concern about the RFC the way it stands right now is that the
 current direction involves E_RECOVERABLE_ERROR instead of E_STRICT or E_CAST
 for data loss.  This results in both consistency issues with casting as well
 as incompatibility with the dynamic nature of PHP scalars.  I know the RFC
 author (Andrea) disagrees with me about it, but I think we need to find a
 way to put this into a much wider decision.  Probably the most practical
 thing to do is to put it as a secondary question in the RFC, although those
 can be tricky.

I do not like these errors either, I would prefer to have the same
than with class arguments, consistent, easy to catch for the
developers. So yes, maybe a 2nd question about how bad arguments
should be handled would be a good thing.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-24 Thread Simon Schick

 My main concern about the RFC the way it stands right now is that the
 current direction involves E_RECOVERABLE_ERROR instead of E_STRICT or E_CAST
 for data loss.  This results in both consistency issues with casting as well
 as incompatibility with the dynamic nature of PHP scalars.  I know the RFC
 author (Andrea) disagrees with me about it, but I think we need to find a
 way to put this into a much wider decision.  Probably the most practical
 thing to do is to put it as a secondary question in the RFC, although those
 can be tricky.

 Zeev


Hi, all

I looked again at the RFC ..

Can someone please update the description at the section Conversion Rules?

This is quoted from the document:

 Conversion is allowed only if data-loss does not happen. There are a few 
 exceptions (objects using __toString, strings containing leading numerics, 
 etc). Here's a table of examples.

But if you look at the table, strings containing leading numbers are
not allowed.

And just as a thought: What about objects where the __toString method
returns a string like 42? Would that also be accepted as an
argument, that just accepts integers? Sounds crazy, but as strings,
only containing numbers, are accepted as integer, we have to take a
decision here and write it down.

Bye
Simon

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 24 Jul 2014, at 13:20, Simon Schick simonsimc...@gmail.com wrote:

 Conversion is allowed only if data-loss does not happen. There are a few 
 exceptions (objects using __toString, strings containing leading numerics, 
 etc). Here's a table of examples.
 
 But if you look at the table, strings containing leading numbers are
 not allowed.

Good catch, fixed.

 And just as a thought: What about objects where the __toString method
 returns a string like 42? Would that also be accepted as an
 argument, that just accepts integers?

No it wouldn’t, as that’s not what cast_object does, existing conversion 
functions do, or what the patch does at present.
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 23 Jul 2014, at 19:37, Andrea Faulds a...@ajf.me wrote:

 
 On 23 Jul 2014, at 19:21, Robert Williams rewilli...@thesba.com wrote:
 
 Also, do int, float, and numeric accept numbers in octal, hex, scientific 
 notation, etc.? I don’t believe there are any examples in the RFC that 
 intentionally or accidentally show what happens with, say, 0x2f as a value.
 
 Ooh, you’ve caught me out there. The patch as it stands would permit such 
 non-decimal numbers, which isn’t what it should do as 
 convert_to_long_base_safe should actually permit only the specified base.
 
 So, yes it does permit non-decimal numbers, but it’s a bug I need to fix.

Said bug has been fixed in the proposed patch now. “0xa” is no longer valid for 
int, float or numeric. It never should’ve been valid, but the implementation of 
convert_to_(long_base|double|numeric)_safe was incorrect.

--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 13 Jul 2014, at 02:57, Andrea Faulds a...@ajf.me wrote:

 The RFC is here: https://wiki.php.net/rfc/scalar_type_hinting_with_cast
 
 A pull request is here: https://github.com/php/php-src/pull/717

I just updated the patch and RFC to include overflow safety for the integer 
type hint. This means that the following code is an error:

function foo(int $a) {}
foo(‘8493284029384029384028409304249230894’);

This is actually a level of safety you couldn’t get with any other proposal. If 
you explicitly cast with (int) it will silently saturate/cap the integer (data 
is lost), and zend_parse_parameters will silently saturate or truncate 
(depending on the function).

This is consistent with passing a float. Were I to do the following, it was 
already an error in the proposal:

function foo(int $a) {}
foo(8493284029384029384028409304249230894.0);

--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 24 Jul 2014, at 09:42, Patrick Schaaf p...@bof.de wrote:

 How does the proposal affect method compatibility between subclasses and 
 baseclasses? Will two methods there, differing in the scalar type annotations 
 of one of their arguments, elicit STRICT warnings, like object type 
 annotations do?

As implemented, yes.

--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-23 Thread Robert Williams

On Jul 14, 2014, at 10:13, Andrea Faulds a...@ajf.me wrote:
 We are using hack’s syntax (int, float, bool, string, no 
 integer/double/boolean aliases).


On 20 Jul 2014, at 14:11, Andrea Faulds a...@ajf.me wrote:
 The patch actually warns you if you try to do this now:

function foo(double $foo) {}
foo(1.0);

 If you use one of the non-existent aliases (double), and pass the type that 
 alias is supposed to hint for (a float), the error message notes you might be 
 looking for the actual type hint (`float`).


It seems odd to me to not support the aliases. Since I can do this:

   $foo = (integer)$bar;

I would expect to be able to do this:

   function foo(integer $param) {}

Also, do int, float, and numeric accept numbers in octal, hex, scientific 
notation, etc.? I don’t believe there are any examples in the RFC that 
intentionally or accidentally show what happens with, say, 0x2f as a value.


--
Bob Williams
SVP, Software Development
Newtek Business Services, Inc.
“The Small Business Authority”
http://www.thesba.com/

Notice: This communication, including attachments, may contain information that 
is confidential. It constitutes non-public information intended to be conveyed 
only to the designated recipient(s). If the reader or recipient of this 
communication is not the intended recipient, an employee or agent of the 
intended recipient who is responsible for delivering it to the intended 
recipient, or if you believe that you have received this communication in 
error, please notify the sender immediately by return e-mail and promptly 
delete this e-mail, including attachments without reading or saving them in any 
manner. The unauthorized use, dissemination, distribution, or reproduction of 
this e-mail, including attachments, is prohibited and may be unlawful. If you 
have received this email in error, please notify us immediately by e-mail or 
telephone and delete the e-mail and the attachments (if any).

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-23 Thread Andrea Faulds


On 23 Jul 2014, at 19:21, Robert Williams rewilli...@thesba.com wrote:

 It seems odd to me to not support the aliases. Since I can do this:
 
   $foo = (integer)$bar;
 
 I would expect to be able to do this:
 
   function foo(integer $param) {}

Aliases mean inconsistency. We shouldn’t unnecessarily have multiple names for 
the same thing, just one. Also, for every alias we support, another reserved 
word is added. Hence we only allow one set of names. This is also Facebook’s 
approach with Hack, which removes the aliases entirely for type casting. I 
might propose we deprecate/remove the aliases in a future RFC.

 Also, do int, float, and numeric accept numbers in octal, hex, scientific 
 notation, etc.? I don’t believe there are any examples in the RFC that 
 intentionally or accidentally show what happens with, say, 0x2f as a value.

Ooh, you’ve caught me out there. The patch as it stands would permit such 
non-decimal numbers, which isn’t what it should do as convert_to_long_base_safe 
should actually permit only the specified base.

So, yes it does permit non-decimal numbers, but it’s a bug I need to fix.

--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-23 Thread Robert Williams

On Jul 23, 2014, at 11:37, Andrea Faulds a...@ajf.me wrote:

 Aliases mean inconsistency. We shouldn’t unnecessarily have multiple names 
 for the same thing, just one. Also, for every alias we support, another 
 reserved word is added. Hence we only allow one set of names. This is also 
 Facebook’s approach with Hack, which removes the aliases entirely for type 
 casting. I might propose we deprecate/remove the aliases in a future RFC.

I agree the aliases, by definition, represent inconsistency. However, that 
inconsistency is already in the language, and those keywords already exist. By 
not supporting the aliases in new functionality that’s so closely related, the 
inconsistency is itself inconsistent.

Although I don’t have voting rights, I would completely support a separate RFC 
to remove the aliases in PHP 6/7. But in the mean time, as long as they’re 
still in the language, I think they need to be fully supported anywhere their 
“real” counterparts can be used. Hack didn’t just remove them in some cases, it 
removed them across the board. And I think that’s the right approach: they’re 
supported across the board until they’re no longer supported, and then they’re 
not supported anywhere.

 So, yes it does permit non-decimal numbers, but it’s a bug I need to fix.

I’m not sure I follow. If I have function foo(int $bar) {}, what happens in 
these cases:

   foo(0x2f);
   foo(‘0x2f’);

Related, is “numeric basically the union of “int” and “float” (as appears to 
be the case from the chart in the RFC), or is it something more along the lines 
of is_numeric()? There could be consistency issues lurking here, too.


Regards,
Bob

--
Robert E. Williams, Jr.
Senior Vice President of Software Development
Newtek Businesss Services, Inc. -- The Small Business Authority
https://www.newtekreferrals.com/rewjr
http://www.thesba.com/


Notice: This communication, including attachments, may contain information that 
is confidential. It constitutes non-public information intended to be conveyed 
only to the designated recipient(s). If the reader or recipient of this 
communication is not the intended recipient, an employee or agent of the 
intended recipient who is responsible for delivering it to the intended 
recipient, or if you believe that you have received this communication in 
error, please notify the sender immediately by return e-mail and promptly 
delete this e-mail, including attachments without reading or saving them in any 
manner. The unauthorized use, dissemination, distribution, or reproduction of 
this e-mail, including attachments, is prohibited and may be unlawful. If you 
have received this email in error, please notify us immediately by e-mail or 
telephone and delete the e-mail and the attachments (if any).

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-23 Thread Andrea Faulds


On 23 Jul 2014, at 22:17, Robert Williams rewilli...@thesba.com wrote:

 Although I don’t have voting rights, I would completely support a separate 
 RFC to remove the aliases in PHP 6/7. But in the mean time, as long as 
 they’re still in the language, I think they need to be fully supported 
 anywhere their “real” counterparts can be used. Hack didn’t just remove them 
 in some cases, it removed them across the board. And I think that’s the right 
 approach: they’re supported across the board until they’re no longer 
 supported, and then they’re not supported anywhere.

Right, but none of the aliases are reserved words already and I really don’t 
want to introduce more reserved words than I have to, otherwise it’s going to 
upset a lot of people.
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-20 Thread Sebastian Bergmann

Am 13.07.2014 07:22, schrieb Stas Malyshev:
 I think it was a mistake to introduce this term from the start and 
 we should stop propagating it.

 What would be a better term? Optional strict typing in function and
 method signatures?

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 20 Jul 2014, at 08:33, Sebastian Bergmann sebast...@php.net wrote:

 Am 13.07.2014 07:22, schrieb Stas Malyshev:
 I think it was a mistake to introduce this term from the start and 
 we should stop propagating it.
 
 What would be a better term? Optional strict typing in function and
 method signatures?

This proposal’s scalar type hints (except for booleans) can’t really be called 
“strict”. Perhaps “firm typing”? (It’s not weak, but it’s not quite strong 
either)
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 18 Jul 2014, at 14:09, Andrea Faulds a...@ajf.me wrote:

 On 18 Jul 2014, at 06:02, Theodore Brown theodor...@outlook.com wrote:
 
 Another concern I have is in regard to the future. I'm looking forward to 
 the 
 possibility of specifying nullable types in a future version of PHP (see 
 Levi Morrison's Declaring Nullable Types RFC: 
 http://wiki.php.net/rfc/nullable_typehints). If the 
 nullable types RFC is accepted, it would be highly disconcerting if scalar 
 type 
 annotations allowed null values regardless of whether a nullable marker is 
 specified.
 
 The current proposed behaviour could be changed. At the moment, if a scalar 
 type hint is nullable, then it won’t cast NULL if it’s passed that value, but 
 if it’s not nullable, then it will cast it.
 
 Considering how this tends to only allow lossless casts, though, it might be 
 worth reconsidering this and just disallowing NULL altogether. It’s worth 
 pointing out that NULL is usually an error value, and you might get it from 
 using an uninitialised variable or calling an internal function with bad 
 parameters.

I’ve updated the RFC and patch to make int, string and double nullability work 
like the other types (bool already did). If the default value isn’t NULL, NULL 
isn’t accepted and you’ll get E_RECOVERABLE_ERROR. If the default value is 
NULL, NULL is accepted and will not be casted.

This will likely lead to less bugs as NULL is a common error value, and it also 
makes the scalar type hints more consistent with the others.
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 20 Jul 2014, at 14:11, Andrea Faulds a...@ajf.me wrote:

 double

Did I just say double? I meant float, of course. :)

The patch actually warns you if you try to do this now:

function foo(double $foo) {}
foo(1.0);

If you use one of the non-existent aliases (double), and pass the type that 
alias is supposed to hint for (a float), the error message notes you might be 
looking for the actual type hint (`float`).

The same for integer and boolean (only int and bool, respectively, are 
permitted).
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 14 Jul 2014, at 17:25, Anthony Ferrara ircmax...@gmail.com wrote:

 And that also hints towards a benefit of adding a numeric hint as well
 (which will accept (and cast to) either an int or a float, exactly how
 is_numeric_string() does internally)... Which is something that may
 want to be considered for this RFC.

I’ve finally gotten round to doing this (I had to fix most of the mess of 
segfaults and broken tests first). The RFC now proposes a ‘numeric’ type hint 
that does what you expect it to, casting to int or float.

The implementation (which is done and tested for this type hint) is 
straightforward, though there’s a minor issue with casting of objects. As 
IS_NUMERIC is a fake type, cast_object doesn’t support it, so it’ll try IS_LONG 
first, unfortunately. Not much we can do about that.

Actually, perhaps it would be possible to try IS_NUMERIC, and if that fails, 
try IS_LONG, then try IS_DOUBLE. Should I do that?

--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-20 Thread Ferenc Kovacs

2014.07.20. 14:43, Andrea Faulds a...@ajf.me ezt írta:


 On 20 Jul 2014, at 08:33, Sebastian Bergmann sebast...@php.net wrote:

  Am 13.07.2014 07:22, schrieb Stas Malyshev:
  I think it was a mistake to introduce this term from the start and
  we should stop propagating it.
 
  What would be a better term? Optional strict typing in function and
  method signatures?

 This proposal’s scalar type hints (except for booleans) can’t really be
called “strict”. Perhaps “firm typing”? (It’s not weak, but it’s not quite
strong either)

Stas and Sebastian are talking about the unfortunate naming of the current
(non-scalar) typehints.

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 20 Jul 2014, at 15:54, Ferenc Kovacs tyr...@gmail.com wrote:

  This proposal’s scalar type hints (except for booleans) can’t really be 
  called “strict”. Perhaps “firm typing”? (It’s not weak, but it’s not quite 
  strong either)
 
 Stas and Sebastian are talking about the unfortunate naming of the current 
 (non-scalar) type hints.

Oh, of course. Perhaps we could say that the non-scalar type hints are 
“optional strict typing” and the scalar type hints are “optional firm typing”?

--
Andrea Faulds
http://ajf.me/





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

RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-20 Thread Theodore Brown

On 18 Jul 2014, at 14:09, Andrea Faulds a...@ajf.me wrote:

 I’ve updated the RFC and patch to make int, string and double nullability 
 work like the other types (bool already did). If the default value isn’t 
 NULL, NULL isn’t accepted and you’ll get E_RECOVERABLE_ERROR. If the default 
 value is NULL, NULL is accepted and will not be casted.

 This will likely lead to less bugs as NULL is a common error value, and it 
 also makes the scalar type hints more consistent with the others.

Thank you very much for making this change. It goes a long way towards making 
scalar type annotations more useful to me as a userland developer. Also, I 
really like the new numeric type hint.

The one remaining issue I have with this proposal is that boolean values are 
currently accepted for every other scalar type except array. As with NULL, 
FALSE is a common error value, and allowing booleans to be passed to a function 
expecting a string or numeric value could easily mask errors and lead to 
hard-to-debug issues in a program. Just as a string cannot be passed to a 
function expecting a boolean, a boolean should not be passed to a function 
expecting a string, etc.

Thanks for all you do for the community.

--

Theodore Brown

A PHP developer interested in the future of the language
  
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-20 Thread Stas Malyshev

Hi!

 
  What would be a better term? Optional strict typing in function and
  method signatures?

Parameter typing, or typed parameters if you will. One of the options,
of course, there could be many others.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-18 Thread Simon Schick

On Fri, Jul 18, 2014 at 7:02 AM, Theodore Brown theodor...@outlook.com wrote:
 Since I am very much in favour of scalar type hints, I've updated the
 patch to master and made some minor improvements, and I am re-opening
 the RFC with the intent to try and get it into PHP 5.7.

 First of all, this is my first reply on PHP Internals so I hope I am doing it 
 right. :)

 Thank you very much Andrea for reviving this RFC - I'm really looking forward 
 to using
 something like this in the next version of PHP to more easily define 
 interfaces and
 catch unintended errors in my code.

 However, something I feel it is important to consider is not just how scalar 
 type
 annotations fit into the history of PHP, but how they fit with the way type 
 annotations
 are currently used and where the language is going in the future.

 A recurring comment I've heard in the discussion for this RFC is that strict 
 type hints
 aren't the PHP way. However, current type hints for classes, arrays, and 
 callables
 work exactly in this way - they do not allow nulls, no casting is performed, 
 and an
 invalid type results in a fatal error. If scalar annotations are introduced, 
 many PHP
 developers (myself included) would naturally expect them to behave in the 
 same way.

 Another concern I have is in regard to the future. I'm looking forward to the
 possibility of specifying nullable types in a future version of PHP (see Levi 
 Morrison's Declaring Nullable Types RFC: 
 http://wiki.php.net/rfc/nullable_typehints). If the
 nullable types RFC is accepted, it would be highly disconcerting if scalar 
 type
 annotations allowed null values regardless of whether a nullable marker is 
 specified.

 I don't think that optional strict type annotations will take away from PHP's 
 dynamic
 nature - they will instead be a valuable feature used in places where it is 
 necessary
 to strictly validate a parameter's type - this is especially important to 
 ensuring
 stability and accuracy in the large PHP applications it is my job to maintain.

 The RFC has already been updated to make boolean type annotations strict. 
 Doesn't it
 make sense to treat the other scalar types in the same way? Perhaps a future 
 RFC could
 propose a second (also optional) syntax to specify type annotations which 
 perform casts.
 However, only having cast-based annotations for scalar types would be a 
 mistake, IMHO.

 --

 Theodore Brown

 A PHP developer interested in the language's future

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


Hi, all

First of all, thanks for all your time, you put into this thread! I
really am looking forward for a way, all can live with, because this
topic has followed the PHP community since the release of PHP 5.1,
since the introduction of type hinting for arrays
(http://php.net/manual/en/language.oop5.typehinting.php).

On an archive for this mailinglist I found threads that are going back
to 2005 (http://marc.info/?l=php-internalsm=112397232722668w=2) -
Here's a list of all messages found:
http://marc.info/?l=php-internalss=type+hintingq=b

I've been one of the most active contributors to a thread back in 2012
- not the one giving most productive feedback, but the one giving the
most feedback ... (I later saw a statistic of who posted the most
mails to the mailinglist within the months of discussion)

What I see, we're again stuck with mainly three different opinions, as
Paul Biggar pointed out in his post - and he tried to find a solution
back then. I would suggest that anyone should read this mail - if you
want, read the thread - I haven't had the time for now..:
http://marc.info/?l=php-internalsm=124653792412529w=2

In every round we took this topic, there have been new RFCs added ...
I don't know if there will be a solution, and my personal favorite is
the way, proposed in this RFC here. No casting for the values, just
more a validation - a lossy validation.

The main reason for this proposal is, that mostly every input to your
application will be a string. If it now is a file, a value from the
database, the GET and POST parameters, a CURL response - nearly
anything. I don't think it makes sense to first cast them before you
can use them.

I agree, that it feels wrong to have a method, accepting
(string)123abc and casting it to (int)123 for internal usage, but it
also feels wrong to not let the input (string)123 pass as a
parameter to a method accepting integer. This would lead us to casting
(f.e. substr(string, (int)$var)  ), what again would be like accept
anything ($var = abc).

I also saw some complaining about that older code may will not work
when introducing something here. As of what I think, this should be
implemented as an extension to the language as it is now. Old code
should be able to run as it is. You may will get a problem when your
old code is using a library, that you want to update and the library
is using the new syntax ;)

Thanks for

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-18 Thread Andrea Faulds


On 18 Jul 2014, at 06:02, Theodore Brown theodor...@outlook.com wrote:

 Another concern I have is in regard to the future. I'm looking forward to the 
 possibility of specifying nullable types in a future version of PHP (see Levi 
 Morrison's Declaring Nullable Types RFC: 
 http://wiki.php.net/rfc/nullable_typehints). If the 
 nullable types RFC is accepted, it would be highly disconcerting if scalar 
 type 
 annotations allowed null values regardless of whether a nullable marker is 
 specified.

The current proposed behaviour could be changed. At the moment, if a scalar 
type hint is nullable, then it won’t cast NULL if it’s passed that value, but 
if it’s not nullable, then it will cast it.

Considering how this tends to only allow lossless casts, though, it might be 
worth reconsidering this and just disallowing NULL altogether. It’s worth 
pointing out that NULL is usually an error value, and you might get it from 
using an uninitialised variable or calling an internal function with bad 
parameters.

--
Andrea Faulds
http://ajf.me/





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

RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-18 Thread Theodore Brown

 Another concern I have is in regard to the future. I'm looking
 forward to the possibility of specifying nullable types in a
 future version of PHP (see Levi Morrison's Declaring Nullable
 Types RFC: http://wiki.php.net/rfc/nullable_typehints). If the
 nullable types RFC is accepted, it would be highly disconcerting
 if scalar type annotations allowed null values regardless of
 whether a nullable marker is specified.

 The current proposed behaviour could be changed. At the moment, if
 a scalar type hint is nullable, then it won’t cast NULL if it’s
 passed that value, but if it’s not nullable, then it will cast it.

 Considering how this tends to only allow lossless casts, though, it
 might be worth reconsidering this and just disallowing NULL
 altogether. It’s worth pointing out that NULL is usually an error
 value, and you might get it from using an uninitialised variable or
 calling an internal function with bad parameters.

The same thing applies to boolean values. FALSE is frequently returned
from internal functions when an error occurs, and allowing it to be
passed to a function expecting a different scalar type could mask errors.

After reading Simon's response I do feel it would be a reasonable
compromise to allow strings to be cast to int/float (and vice versa) as
long as no data loss occurs (following the current rules in the RFC).
If the RFC is updated to disallow NULL altogether and also disallow
boolean values for other scalar types I would be 100% supportive.

--

Theodore Brown

A PHP developer interested in the future of the language

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-17 Thread Thomas Nunninger


Hi,

On 07/16/2014 10:45 PM, Andrea Faulds wrote:


On 16 Jul 2014, at 21:43, Zeev Suraski z...@zend.com wrote:


anything this RFC permits will
be permitted by zpp, it's the reverse that isn't necessarily true.


Right, so it needs to be fixed.  It makes no sense to force a new agenda
on the language that's inconsistent with the rest of the language.  Align
your new feature to the rest of the language, not the other way around.


But to do so would be to make the feature less useful, nor satisfy people who 
want stricter hinting.


tl;dr:

- I'd like to have E_CAST on all castings/type jugglings even if we do 
not get scalar type hinting.


- I propose to say/implement scalar parameter casting instead of 
scalar type hinting with a casting syntax:


function foo( (int) $i, ...)

That way we lower expectations, explain the different syntax/semantics 
in contrast to hints, give a hint what scalar parameter casting does, 
and I see the use-cases of both parties fulfilled.


---

I didn't follow the complete thread in detail. And I have to confess 
that I'm a big fan of strictly defining types of parameters, because I 
see how it could help me in my work.


BUT: As I see it, E_CAST (with the existing type juggling rules/casts) 
plus scalar parameter casting is the best compromise in the 
spirit/history of PHP without BC breaks and I think all use-cases are 
satisfied:



- E_CAST notifies me about data loss on type juggling.

- scalar parameter casting should just be a convenience for coding:

function foo( (int) $i, (string) $s )
{
}

  is the same as:

function foo( $i, $s )
{
  $i = (int) $i;
  $s = (string) $s;
}

  or perhaps better::

$i = (int) $i;
$s = (string) $s;

foo( $i, $s );


That way you decide if you want to be very strict about the data in your 
variables or not, and both parties (strict vs. non-strict) can share code:



- With E_CAST you get additional information on data loss on type 
juggling and casting in your complete code base. That's a plus for 
everybody who's a little bit scary about type juggling in those cases.


- As a fan of strict mode I can develop my applications and libraries in 
E_CAST mode via an error handler that throws exceptions on E_CAST. (We 
even run our code with E_ALL in production to find edge cases.)


- I see the severity of E_CAST on a level like E_NOTICE and E_STRICT: 
Best practice - if others do not understand/care it's their problem 
but they can use my code like each other code.


- As a fan of non-strict behavior, you can provide a string for a 
parameter that is defined to be an integer. If it contains a number you 
are happy that my code works as PHP deals with casting. If your string 
does not contain a usable value you have to live with the good old PHP 
way when you use code with wrong input data and my code treats it as an 
integer and you perhaps have some data loss. But that's not the 
responsibility of my code - especially if I interpret the casting syntax 
as casting the parameters before hitting my method/function. (BTW: I 
don't think that casting should be used as sanitizing of user input like 
it was proposed/said to be widely used. I prefer validation over 
sanitizing.)


- Depending where and how I define my error handler, I do not see that 
my code needs to behave differently if E_CAST is enabled or not. I think 
you should implement your error_handler for E_CAST in the spirit of 
Symfony's debug mode: In debug mode all errors are converted to 
exceptions but they are ignored in production mode. I guess you'd never 
say: My application behaves differently. Otherwise you probably use 
exceptions for control flow. (I do not say that you have to disable 
E_CAST for your production mode. But if your code passes all tests in 
E_CAST, there is a good chance that it works without E_CAST as well. 
Then it's your decision as product owner if you have to break on errors 
in edge cases or not.)


- Regarding consistency to array and object hints: Using the casting 
syntax/semantics you could even provide (array) and (object) as scalar 
parameter casting in contrast to the hints. But of course you can argue 
that users are confused about (array) vs. array. I could live with 
that confusion as people have to learn about parameter casting and 
that should be explicitly mentioned in the docs/tutorials/blog posts/...


- I don't know if there is a downside for static code analysis. But 
probably you even need defined return types for that.



Regards

Thomas

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

RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-17 Thread Robert Stoll

 -Original Message-
 From: Alain Williams [mailto:a...@phcomp.co.uk]
 Sent: Wednesday, July 16, 2014 11:17 AM
 To: internals@lists.php.net
 Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

 On Wed, Jul 16, 2014 at 09:31:46AM +0100, Rowan Collins wrote:

  Now, one form of compromise is to use variants of the syntax, such as...

  function foo((int) $bar)
  function foo(-int $bar)
  ...

 A slight tangent, but *if* this sort of syntax is adopted we need to think 
 what
 will happen when someone puts a class name in there instead of a basic type.

 I would suggest that it be a compile error of some sort if the 'type' is
 anything other than int, float,  The only one that may make sense is

 function foo((array) $bar)

 If $bar is not an array it would make an array containing one element with 
 value $bar.

 --
 Alain Williams
 Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
 Lecturer.
 +44 (0) 787 668 0256  http://www.phcomp.co.uk/
 Parliament Hill Computers Ltd. Registration Information: 
 http://www.phcomp.co.uk/contact.php
 #include std_disclaimer.h

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

In case this RFC should go with a compromise and introduces two syntax (one for 
strict check, one which includes
casting) it might be worth considering to use the same syntax as TSPHP. TSPHP 
has introduced a cast modifier also for
function/method parameters which has the effect, that actual parameters are 
casted to the formal parameter type if
necessary and applicable:
https://tsphp.ch/wiki/display/TSPHP/cast+modifier

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-17 Thread Dan Ackroyd

Thomas Nunninger wrote:
 - scalar parameter casting should just be a convenience for coding:

  function foo( (int) $i, (string) $s )
  {
  }

is the same as:

  function foo( $i, $s )
  {
$i = (int) $i;
$s = (string) $s;
  }

or perhaps better::

  $i = (int) $i;
  $s = (string) $s;

  foo( $i, $s );


 That way you decide if you want to be very strict about the data in your
 variables or not, and both parties (strict vs. non-strict) can share code:

I agree generally with your mail apart from this bit - people don't
always just call code directly and so can't tell what types parameters
should be.

When you're calling code dynamically, e.g. through a dependency
injection container, you need to be able to inspect what types are
expected from outside the function.

e.g.

$dic-execute(
'foo',
[
'i' = $request-getParam('i'),
's' = $request-getParam('s')
]
);

Without having the type-hinting/casting information available in the
function, it's not possible for the calling code to know what type the
function is expecting, and so it isn't able to cast it to what the
function is expecting.

cheers
Dan

On 17 July 2014 10:22, Thomas Nunninger tho...@nunninger.info wrote:
 Hi,

 On 07/16/2014 10:45 PM, Andrea Faulds wrote:


 On 16 Jul 2014, at 21:43, Zeev Suraski z...@zend.com wrote:

 anything this RFC permits will
 be permitted by zpp, it's the reverse that isn't necessarily true.


 Right, so it needs to be fixed.  It makes no sense to force a new agenda
 on the language that's inconsistent with the rest of the language.  Align
 your new feature to the rest of the language, not the other way around.


 But to do so would be to make the feature less useful, nor satisfy people
 who want stricter hinting.


 tl;dr:

 - I'd like to have E_CAST on all castings/type jugglings even if we do not
 get scalar type hinting.

 - I propose to say/implement scalar parameter casting instead of scalar
 type hinting with a casting syntax:

 function foo( (int) $i, ...)

 That way we lower expectations, explain the different syntax/semantics in
 contrast to hints, give a hint what scalar parameter casting does, and I see
 the use-cases of both parties fulfilled.

 ---

 I didn't follow the complete thread in detail. And I have to confess that
 I'm a big fan of strictly defining types of parameters, because I see how
 it could help me in my work.

 BUT: As I see it, E_CAST (with the existing type juggling rules/casts) plus
 scalar parameter casting is the best compromise in the spirit/history of
 PHP without BC breaks and I think all use-cases are satisfied:


 - E_CAST notifies me about data loss on type juggling.

 - scalar parameter casting should just be a convenience for coding:

 function foo( (int) $i, (string) $s )
 {
 }

   is the same as:

 function foo( $i, $s )
 {
   $i = (int) $i;
   $s = (string) $s;
 }

   or perhaps better::

 $i = (int) $i;
 $s = (string) $s;

 foo( $i, $s );


 That way you decide if you want to be very strict about the data in your
 variables or not, and both parties (strict vs. non-strict) can share code:


 - With E_CAST you get additional information on data loss on type juggling
 and casting in your complete code base. That's a plus for everybody who's a
 little bit scary about type juggling in those cases.

 - As a fan of strict mode I can develop my applications and libraries in
 E_CAST mode via an error handler that throws exceptions on E_CAST. (We even
 run our code with E_ALL in production to find edge cases.)

 - I see the severity of E_CAST on a level like E_NOTICE and E_STRICT: Best
 practice - if others do not understand/care it's their problem but they
 can use my code like each other code.

 - As a fan of non-strict behavior, you can provide a string for a parameter
 that is defined to be an integer. If it contains a number you are happy that
 my code works as PHP deals with casting. If your string does not contain a
 usable value you have to live with the good old PHP way when you use code
 with wrong input data and my code treats it as an integer and you perhaps
 have some data loss. But that's not the responsibility of my code -
 especially if I interpret the casting syntax as casting the parameters
 before hitting my method/function. (BTW: I don't think that casting should
 be used as sanitizing of user input like it was proposed/said to be widely
 used. I prefer validation over sanitizing.)

 - Depending where and how I define my error handler, I do not see that my
 code needs to behave differently if E_CAST is enabled or not. I think you
 should implement your error_handler for E_CAST in the spirit of Symfony's
 debug mode: In debug mode all errors are converted to exceptions but they
 are ignored in production mode. I guess you'd never say: My application
 behaves differently. Otherwise you probably use exceptions for control flow.
 (I

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-17 Thread Thomas Nunninger


Hi Dan,

On 07/17/2014 02:12 PM, Dan Ackroyd wrote:

Thomas Nunninger wrote:

- scalar parameter casting should just be a convenience for coding:

  function foo( (int) $i, (string) $s )
  {
  }

is the same as:

  function foo( $i, $s )
  {
$i = (int) $i;
$s = (string) $s;
  }

or perhaps better::

  $i = (int) $i;
  $s = (string) $s;

  foo( $i, $s );


That way you decide if you want to be very strict about the data in your
variables or not, and both parties (strict vs. non-strict) can share code:


I agree generally with your mail apart from this bit - people don't
always just call code directly and so can't tell what types parameters
should be.

When you're calling code dynamically, e.g. through a dependency
injection container, you need to be able to inspect what types are
expected from outside the function.

e.g.

$dic-execute(
 'foo',
 [
 'i' = $request-getParam('i'),
 's' = $request-getParam('s')
 ]
);

Without having the type-hinting/casting information available in the
function, it's not possible for the calling code to know what type the
function is expecting, and so it isn't able to cast it to what the
function is expecting.


Perhaps I miss your point. But what is the difference to current 
behavior if you do not know about the types?


With casting the calling code does not need to know how to cast as the 
called code accepts the parameter if the value can be used without data 
loss. (If the example was misleading because the cast is happening 
before calling the function: This should only stress, that providing 
usable data is not a responsibility of the called function but the 
calling code.)


If the called function is strict it checks the input parameters in the 
function and raises some kind of error if information is lost on casting 
(not if the type is wrong). If information is lost, E_CAST is raised and 
PHP would use type juggling with expected or unexpected result (e.g. 
non-numeric strings casted to int). The difference to current behavior 
is that the product owner can decide if he wants strict behavior or not.



Or is your point about inspection of parameter type? Why shouldn't 
reflection be able to provide information about scalar parameter casting?


Regards

Thomas


On 17 July 2014 10:22, Thomas Nunninger tho...@nunninger.info wrote:

Hi,

On 07/16/2014 10:45 PM, Andrea Faulds wrote:



On 16 Jul 2014, at 21:43, Zeev Suraski z...@zend.com wrote:


anything this RFC permits will
be permitted by zpp, it's the reverse that isn't necessarily true.



Right, so it needs to be fixed.  It makes no sense to force a new agenda
on the language that's inconsistent with the rest of the language.  Align
your new feature to the rest of the language, not the other way around.



But to do so would be to make the feature less useful, nor satisfy people
who want stricter hinting.



tl;dr:

- I'd like to have E_CAST on all castings/type jugglings even if we do not
get scalar type hinting.

- I propose to say/implement scalar parameter casting instead of scalar
type hinting with a casting syntax:

 function foo( (int) $i, ...)

That way we lower expectations, explain the different syntax/semantics in
contrast to hints, give a hint what scalar parameter casting does, and I see
the use-cases of both parties fulfilled.

---

I didn't follow the complete thread in detail. And I have to confess that
I'm a big fan of strictly defining types of parameters, because I see how
it could help me in my work.

BUT: As I see it, E_CAST (with the existing type juggling rules/casts) plus
scalar parameter casting is the best compromise in the spirit/history of
PHP without BC breaks and I think all use-cases are satisfied:


- E_CAST notifies me about data loss on type juggling.

- scalar parameter casting should just be a convenience for coding:

 function foo( (int) $i, (string) $s )
 {
 }

   is the same as:

 function foo( $i, $s )
 {
   $i = (int) $i;
   $s = (string) $s;
 }

   or perhaps better::

 $i = (int) $i;
 $s = (string) $s;

 foo( $i, $s );


That way you decide if you want to be very strict about the data in your
variables or not, and both parties (strict vs. non-strict) can share code:


- With E_CAST you get additional information on data loss on type juggling
and casting in your complete code base. That's a plus for everybody who's a
little bit scary about type juggling in those cases.

- As a fan of strict mode I can develop my applications and libraries in
E_CAST mode via an error handler that throws exceptions on E_CAST. (We even
run our code with E_ALL in production to find edge cases.)

- I see the severity of E_CAST on a level like E_NOTICE and E_STRICT: Best
practice - if others do not understand/care it's their problem but they
can use my code like each other code.

- As a fan of non-strict behavior, you can provide a string for a parameter

RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-17 Thread Christian Stoller

 - I'd like to have E_CAST on all castings/type jugglings even if we do 
 not get scalar type hinting.

$var = 6.3;
$a = (int) $var;

Or $b = (bool) 1;

This is usual code and it could be wanted to losse information on casting. 
Triggering errors for that would be extremely annoying.


 - I propose to say/implement scalar parameter casting instead of 
 scalar type hinting with a casting syntax:
 
  function foo( (int) $i, ...)

That's bad to read, destroys the possibility to integrate method overloading 
one day in the future, and it is telling the wrong story.

If I have function moo(int $var) it shows that the method expects an integer.
If I have function moo((int) $var) it looks like: Give me whatever you want 
and I cast it into an integer.

Christian

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-17 Thread Dan Ackroyd

Hi Thomas,

 Perhaps I miss your point. But what is the difference to current behavior if 
 you do not know about the types?

Not to the current behaviour, to the behaviour that would be possible
with scalar type-hinting.

Or is your point about inspection of parameter type?  Why shouldn't reflection 
be able to provide information about scalar parameter casting?

Yes, reflection should provide that information which makes the code:

  function foo( $i, $s )
  {
$i = (int) $i;
$s = (string) $s;
  }


Not be equivalent to:

  function foo( $i, $s )
  {
$i = (int) $i;
$s = (string) $s;
  }

My point is the reflection then allows the calling code to explicitly
cast the parameters to the type the function expects, _with_ data loss
if required, without triggering any warning on information loss. For
example:

function foo(bool $enabled) {...}

$enabledValue = $request-getParam('enabled');

$dic-execute('foo', ['enabled' = $enabledValue ] )

The DIC should be able to know that the function expects a bool and so
if the value of $enabledValue is the string 'true', that it should
convert it to the boolean true, and so make the function happy. So
that allows no E_CAST being generated, as there has been no implicit
cast, only an explicit conversion somewhere in the DIC.

cheers
Dan

On 17 July 2014 13:43, Thomas Nunninger tho...@nunninger.info wrote:
 Hi Dan,


 On 07/17/2014 02:12 PM, Dan Ackroyd wrote:

 Thomas Nunninger wrote:

 - scalar parameter casting should just be a convenience for coding:

   function foo( (int) $i, (string) $s )
   {
   }

 is the same as:

   function foo( $i, $s )
   {
 $i = (int) $i;
 $s = (string) $s;
   }

 or perhaps better::

   $i = (int) $i;
   $s = (string) $s;

   foo( $i, $s );


 That way you decide if you want to be very strict about the data in your
 variables or not, and both parties (strict vs. non-strict) can share
 code:


 I agree generally with your mail apart from this bit - people don't
 always just call code directly and so can't tell what types parameters
 should be.

 When you're calling code dynamically, e.g. through a dependency
 injection container, you need to be able to inspect what types are
 expected from outside the function.

 e.g.

 $dic-execute(
  'foo',
  [
  'i' = $request-getParam('i'),
  's' = $request-getParam('s')
  ]
 );

 Without having the type-hinting/casting information available in the
 function, it's not possible for the calling code to know what type the
 function is expecting, and so it isn't able to cast it to what the
 function is expecting.


 Perhaps I miss your point. But what is the difference to current behavior if
 you do not know about the types?

 With casting the calling code does not need to know how to cast as the
 called code accepts the parameter if the value can be used without data
 loss. (If the example was misleading because the cast is happening before
 calling the function: This should only stress, that providing usable data is
 not a responsibility of the called function but the calling code.)

 If the called function is strict it checks the input parameters in the
 function and raises some kind of error if information is lost on casting
 (not if the type is wrong). If information is lost, E_CAST is raised and PHP
 would use type juggling with expected or unexpected result (e.g. non-numeric
 strings casted to int). The difference to current behavior is that the
 product owner can decide if he wants strict behavior or not.


 Or is your point about inspection of parameter type? Why shouldn't
 reflection be able to provide information about scalar parameter casting?

 Regards

 Thomas


 On 17 July 2014 10:22, Thomas Nunninger tho...@nunninger.info wrote:

 Hi,

 On 07/16/2014 10:45 PM, Andrea Faulds wrote:



 On 16 Jul 2014, at 21:43, Zeev Suraski z...@zend.com wrote:

 anything this RFC permits will
 be permitted by zpp, it's the reverse that isn't necessarily true.



 Right, so it needs to be fixed.  It makes no sense to force a new
 agenda
 on the language that's inconsistent with the rest of the language.
 Align
 your new feature to the rest of the language, not the other way around.



 But to do so would be to make the feature less useful, nor satisfy
 people
 who want stricter hinting.



 tl;dr:

 - I'd like to have E_CAST on all castings/type jugglings even if we do
 not
 get scalar type hinting.

 - I propose to say/implement scalar parameter casting instead of
 scalar
 type hinting with a casting syntax:

  function foo( (int) $i, ...)

 That way we lower expectations, explain the different syntax/semantics in
 contrast to hints, give a hint what scalar parameter casting does, and I
 see
 the use-cases of both parties fulfilled.

 ---

 I didn't follow the complete thread in detail. And I have to confess that
 I'm a big fan of strictly defining types of

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-17 Thread Dan Ackroyd

Apologies, I pasted the wrong code, it should have read:


which makes the code:

  function foo( $i, $s )
  {
$i = (int) $i;
$s = (string) $s;
  }

Not be equivalent to:

 function foo( (int) $i, (string) $s )
  {
  }

As the type-hint information is not available outside the function for
the first one.




On 17 July 2014 19:29, Dan Ackroyd dan...@basereality.com wrote:
 Hi Thomas,

 Perhaps I miss your point. But what is the difference to current behavior if 
 you do not know about the types?

 Not to the current behaviour, to the behaviour that would be possible
 with scalar type-hinting.

Or is your point about inspection of parameter type?  Why shouldn't 
reflection be able to provide information about scalar parameter casting?

 Yes, reflection should provide that information which makes the code:

  function foo( $i, $s )
  {
$i = (int) $i;
$s = (string) $s;
  }


 Not be equivalent to:

  function foo( $i, $s )
  {
$i = (int) $i;
$s = (string) $s;
  }

 My point is the reflection then allows the calling code to explicitly
 cast the parameters to the type the function expects, _with_ data loss
 if required, without triggering any warning on information loss. For
 example:

 function foo(bool $enabled) {...}

 $enabledValue = $request-getParam('enabled');

 $dic-execute('foo', ['enabled' = $enabledValue ] )

 The DIC should be able to know that the function expects a bool and so
 if the value of $enabledValue is the string 'true', that it should
 convert it to the boolean true, and so make the function happy. So
 that allows no E_CAST being generated, as there has been no implicit
 cast, only an explicit conversion somewhere in the DIC.

 cheers
 Dan

 On 17 July 2014 13:43, Thomas Nunninger tho...@nunninger.info wrote:
 Hi Dan,


 On 07/17/2014 02:12 PM, Dan Ackroyd wrote:

 Thomas Nunninger wrote:

 - scalar parameter casting should just be a convenience for coding:

   function foo( (int) $i, (string) $s )
   {
   }

 is the same as:

   function foo( $i, $s )
   {
 $i = (int) $i;
 $s = (string) $s;
   }

 or perhaps better::

   $i = (int) $i;
   $s = (string) $s;

   foo( $i, $s );


 That way you decide if you want to be very strict about the data in your
 variables or not, and both parties (strict vs. non-strict) can share
 code:


 I agree generally with your mail apart from this bit - people don't
 always just call code directly and so can't tell what types parameters
 should be.

 When you're calling code dynamically, e.g. through a dependency
 injection container, you need to be able to inspect what types are
 expected from outside the function.

 e.g.

 $dic-execute(
  'foo',
  [
  'i' = $request-getParam('i'),
  's' = $request-getParam('s')
  ]
 );

 Without having the type-hinting/casting information available in the
 function, it's not possible for the calling code to know what type the
 function is expecting, and so it isn't able to cast it to what the
 function is expecting.


 Perhaps I miss your point. But what is the difference to current behavior if
 you do not know about the types?

 With casting the calling code does not need to know how to cast as the
 called code accepts the parameter if the value can be used without data
 loss. (If the example was misleading because the cast is happening before
 calling the function: This should only stress, that providing usable data is
 not a responsibility of the called function but the calling code.)

 If the called function is strict it checks the input parameters in the
 function and raises some kind of error if information is lost on casting
 (not if the type is wrong). If information is lost, E_CAST is raised and PHP
 would use type juggling with expected or unexpected result (e.g. non-numeric
 strings casted to int). The difference to current behavior is that the
 product owner can decide if he wants strict behavior or not.


 Or is your point about inspection of parameter type? Why shouldn't
 reflection be able to provide information about scalar parameter casting?

 Regards

 Thomas


 On 17 July 2014 10:22, Thomas Nunninger tho...@nunninger.info wrote:

 Hi,

 On 07/16/2014 10:45 PM, Andrea Faulds wrote:



 On 16 Jul 2014, at 21:43, Zeev Suraski z...@zend.com wrote:

 anything this RFC permits will
 be permitted by zpp, it's the reverse that isn't necessarily true.



 Right, so it needs to be fixed.  It makes no sense to force a new
 agenda
 on the language that's inconsistent with the rest of the language.
 Align
 your new feature to the rest of the language, not the other way around.



 But to do so would be to make the feature less useful, nor satisfy
 people
 who want stricter hinting.



 tl;dr:

 - I'd like to have E_CAST on all castings/type jugglings even if we do
 not
 get scalar type hinting.

 - I propose to say/implement scalar

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-17 Thread Theodore Brown

 Since I am very much in favour of scalar type hints, I've updated the
 patch to master and made some minor improvements, and I am re-opening
 the RFC with the intent to try and get it into PHP 5.7.

First of all, this is my first reply on PHP Internals so I hope I am doing it 
right. :)

Thank you very much Andrea for reviving this RFC - I'm really looking forward 
to using 
something like this in the next version of PHP to more easily define interfaces 
and 
catch unintended errors in my code.

However, something I feel it is important to consider is not just how scalar 
type 
annotations fit into the history of PHP, but how they fit with the way type 
annotations 
are currently used and where the language is going in the future.

A recurring comment I've heard in the discussion for this RFC is that strict 
type hints
aren't the PHP way. However, current type hints for classes, arrays, and 
callables 
work exactly in this way - they do not allow nulls, no casting is performed, 
and an 
invalid type results in a fatal error. If scalar annotations are introduced, 
many PHP 
developers (myself included) would naturally expect them to behave in the same 
way.

Another concern I have is in regard to the future. I'm looking forward to the 
possibility of specifying nullable types in a future version of PHP (see Levi 
Morrison's Declaring Nullable Types RFC: 
http://wiki.php.net/rfc/nullable_typehints). If the 
nullable types RFC is accepted, it would be highly disconcerting if scalar type 
annotations allowed null values regardless of whether a nullable marker is 
specified.

I don't think that optional strict type annotations will take away from PHP's 
dynamic
nature - they will instead be a valuable feature used in places where it is 
necessary
to strictly validate a parameter's type - this is especially important to 
ensuring
stability and accuracy in the large PHP applications it is my job to maintain.

The RFC has already been updated to make boolean type annotations strict. 
Doesn't it 
make sense to treat the other scalar types in the same way? Perhaps a future 
RFC could
propose a second (also optional) syntax to specify type annotations which 
perform casts.
However, only having cast-based annotations for scalar types would be a 
mistake, IMHO.

--

Theodore Brown

A PHP developer interested in the language's future
  
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


Andrey Andreev wrote (on 15/07/2014):


I'm sorry, I know what you mean here and I'm not criticizing you
specifically (in fact, I'm intentionally taking it ouf of context),
but that's PHP internals, not PHP community.


Point taken, but there's plenty of overlap between the two; it's not 
like everyone on this list is a 1337 hardcore C hacker who only writes 
PHP code to test their latest cool patch to the Zend Engine. It would be 
interesting to have this debate at a PHP conference or large user-group 
and see if it came out the same way, but I've no particular reason to 
suppose it wouldn't.



Unless you really force the camps to pick one by saying you can't
have Y if we've got X (to which there's no technical limitation, so
that's not true)


That's fine, as long as you don't count the syntax as part of the 
feature.  Since everybody would like their preferred version to be 
written the same way, then, yes, there's a very obvious technical 
limitation: given


function foo(int $bar)

there has to be a single interpretation. As soon as that interpretation 
is chosen, it is chosen for all time, and there is no way we can make it 
mean something else later.


Now, one form of compromise is to use variants of the syntax, such as...

function foo((int) $bar)
function foo(-int $bar)
function foo(+int $bar)
function foo(~int $bar)
function foo(int! $bar)
etc

...but we still have to decide which behaviour to implement first, and 
which syntax to give it.


There's also variants of some of the features that really wouldn't make 
sense to pick two of: I don't think anyone wants a language which has 
weak cast, strict cast, and really strict cast alongside each 
other. So we can't just say implement all the versions and let users 
choose, either.


I appreciate the frustration of the debate going round in circles, I 
feel it too. But without a benevolent dictator, we have to somehow reach 
a compromise. Feel free to suggest your preferred compromise, as long as 
it's not just do the one I want and maybe other people can add theirs 
later with an as-yet-unspecified syntax (not that that is what you were 
asking for, exactly, I've taken it to extremes to make a point).


Regards,
--
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-16 Thread Alain Williams

On Wed, Jul 16, 2014 at 09:31:46AM +0100, Rowan Collins wrote:

 Now, one form of compromise is to use variants of the syntax, such as...
 
 function foo((int) $bar)
 function foo(-int $bar)
 ...

A slight tangent, but *if* this sort of syntax is adopted we need to think what
will happen when someone puts a class name in there instead of a basic type.

I would suggest that it be a compile error of some sort if the 'type' is
anything other than int, float,  The only one that may make sense is

function foo((array) $bar)

If $bar is not an array it would make an array containing one element with 
value $bar.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
http://www.phcomp.co.uk/contact.php
#include std_disclaimer.h

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-16 Thread Andrey Andreev

On Tue, Jul 15, 2014 at 11:05 PM, Andrea Faulds a...@ajf.me wrote:

 On 15 Jul 2014, at 21:02, Andrey Andreev n...@devilix.net wrote:

 Unless you really force the camps to pick one by saying you can't
 have Y if we've got X (to which there's no technical limitation, so
 that's not true)

 No technical limitation, sure, but it would be really weird for PHP to go in 
 two completely opposite directions at the same time!

Depending on what we're talking about, it could be two directions or
two very high-level features that wouldn't have room for more
improvement, making them boundaries, not directions.

By trying to be abstract in my previous writing, I guess I didn't
clarify what I'm referring to by X and Y. Read below please. :)

On Wed, Jul 16, 2014 at 11:31 AM, Rowan Collins rowan.coll...@gmail.com wrote:
 Andrey Andreev wrote (on 15/07/2014):


 I'm sorry, I know what you mean here and I'm not criticizing you
 specifically (in fact, I'm intentionally taking it ouf of context),
 but that's PHP internals, not PHP community.


 Point taken, but there's plenty of overlap between the two; it's not like
 everyone on this list is a 1337 hardcore C hacker who only writes PHP code
 to test their latest cool patch to the Zend Engine. It would be interesting
 to have this debate at a PHP conference or large user-group and see if it
 came out the same way, but I've no particular reason to suppose it wouldn't.

That is true to some extent, but the majority of regular participants
in these discussions are the ones who write the C code. Also, the
conclusion that I quoted is (I believe) based on previously rejected
proposals for scalar type hints. Ultimately, only that same group of
people can reject it, because they are the voters.

 Unless you really force the camps to pick one by saying you can't
 have Y if we've got X (to which there's no technical limitation, so
 that's not true)


 That's fine, as long as you don't count the syntax as part of the feature.
 Since everybody would like their preferred version to be written the same
 way, then, yes, there's a very obvious technical limitation: given

 function foo(int $bar)

 there has to be a single interpretation. As soon as that interpretation is
 chosen, it is chosen for all time, and there is no way we can make it mean
 something else later.

 Now, one form of compromise is to use variants of the syntax, such as...

 function foo((int) $bar)
 function foo(-int $bar)
 function foo(+int $bar)
 function foo(~int $bar)
 function foo(int! $bar)
 etc

 ...but we still have to decide which behaviour to implement first, and which
 syntax to give it.

Exactly my point. I had already expressed my support for using another
syntax, because if the current one is used for type cast hints, then
strict type hints would be practically impossible in the future.

 There's also variants of some of the features that really wouldn't make
 sense to pick two of: I don't think anyone wants a language which has weak
 cast, strict cast, and really strict cast alongside each other. So we
 can't just say implement all the versions and let users choose, either.

 I appreciate the frustration of the debate going round in circles, I feel it
 too. But without a benevolent dictator, we have to somehow reach a
 compromise. Feel free to suggest your preferred compromise, as long as it's
 not just do the one I want and maybe other people can add theirs later with
 an as-yet-unspecified syntax (not that that is what you were asking for,
 exactly, I've taken it to extremes to make a point).

Of course, I am not suggesting to introduce 3 different kinds of
casting rules. X vs Y in my case point was type cast hints vs strict
type hints.
I understand that this RFC is about type cast hints and that's fine
with me. My problem with it is that every suggestion for a change in
it is shot down via rhetorics built around the dogma that PHP is a
weakly typed language or that we're talking about a different feature
here, completely ignoring the concern that keeping it as is may
prevent another useful feature from being implemented in the future.

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

RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

 -Original Message-
 From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
 Sent: Tuesday, July 15, 2014 7:14 PM
 To: Rowan Collins; internals@lists.php.net
 Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

 Hi!

  The answer - which is definitely a matter of opinion - is that
  allowing any string reduces the usefulness of the type hint.

 IMO, having consistent rules is much more, orders of magnitude more
 important than serving any particular use case. We will always have use
 cases
 in which any particular check would not be enough. We should not sacrifice
 the simplicity of the language to try and capture every one of them.

Agreed.

Zeev

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

RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

 -Original Message-
 From: Andrea Faulds [mailto:a...@ajf.me]
 Sent: Tuesday, July 15, 2014 10:48 PM
 To: Andrey Andreev
 Cc: Rowan Collins; Stas Malyshev; internals@lists.php.net
 Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

 On 15 Jul 2014, at 20:43, Andrey Andreev n...@devilix.net wrote:

  I'm sorry, I know what you mean here and I'm not criticizing you
  specifically (in fact, I'm intentionally taking it ouf of context),
  but that's PHP internals, not PHP community.

  The PHP community that I know, wants to have _both_ type cast hinting
  and strict type declarations.

 I'm not sure that's quite the case. There are camps wanting one, there
are
 camps wanting the other, I suppose some want both, but to me that seems
like
 a not-a-compromise compromise solution. The point of this RFC, to some
 extent, is to be a reasonable compromise between completely strict
 declarations and cast hinting, providing the safety of the first and the
flexibility
 of the second. I think it strikes the balance well.

For me the introduction of a new set of rules is a deal breaker.
I'm -1 on the RFC the way it is, and +1 if we implement these 'hints' as
implicit casts, plus change implicit casts to emit E_CAST in case of loss
of data or 'bogus' conversions.

Why insist E_RECOVERABLE_ERROR and introduce this effectively new set of
rules, instead of switching to E_CAST and maintain consistency?
Maintaining consistency is a HUGE deal.  Every such feature we add that
you need to learn more rules/exceptions for make PHP harder to learn.

Zeev

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

RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-16 Thread Pierre Joye

On Jul 16, 2014 4:29 PM, Zeev Suraski z...@zend.com wrote:

 For me the introduction of a new set of rules is a deal breaker.
 I'm -1 on the RFC the way it is, and +1 if we implement these 'hints' as
 implicit casts, plus change implicit casts to emit E_CAST in case of loss
 of data or 'bogus' conversions.

I am -1 in yet another error (as in E_*), which will be just as painful to
deal with than any other.

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


Zeev Suraski wrote (on 16/07/2014):

For me the introduction of a new set of rules is a deal breaker.
I'm -1 on the RFC the way it is, and +1 if we implement these 'hints' as
implicit casts, plus change implicit casts to emit E_CAST in case of loss
of data or 'bogus' conversions.


Just to be clear, implementing E_CAST would require introducing a set of 
rules for when to throw it. By a strict reading of your message, that's 
a deal breaker.


In other words, you can't make an omelette without breaking eggs. We can 
choose not to make the omelette, or we can choose which eggs to break.


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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


Stas Malyshev wrote (on 15/07/2014):

Hi!


That's only a problem if you frame the new hints as a type of implicit
cast. If they were to be described in relation to existing
functionality, I'd describe them as a new type of *explicit* cast, but

How they are explicit cast if you're not explicitly casing anything?


I was thinking of them as explicit within the function definition, 
rather than within the calling code. I guess a cast always explicitly 
happens *somewhere*, so it's a matter of interpretation, but this is the 
rough equivalence which made me think of it as explicit:


function foo(int $bar) {
}
function foo($bar) {
$bar = (int)$bar;
}

In contrast, if you write '123' + '456', you never mention int at all, 
but an implicit cast happens to both arguments.



as mentioned elsewhere, I'd be happy for them to exist outside of
function signatures too as a new notion of strict cast.

That's exactly what I want to avoid - having several forms of casts with
different rules. One is good, two is kind of OK, three is too much.


As far as I know there's only one set of rules at the moment, and I'm 
suggesting adding a second. So, kind of OK. Unless I'm missing 
something about what we currently have.



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

RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

 -Original Message-
 From: Rowan Collins [mailto:rowan.coll...@gmail.com]
 Sent: Wednesday, July 16, 2014 1:25 PM
 To: internals@lists.php.net
 Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

 Zeev Suraski wrote (on 16/07/2014):
  For me the introduction of a new set of rules is a deal breaker.
  I'm -1 on the RFC the way it is, and +1 if we implement these 'hints'
  as implicit casts, plus change implicit casts to emit E_CAST in case
  of loss of data or 'bogus' conversions.

 Just to be clear, implementing E_CAST would require introducing a set of
 rules
 for when to throw it. By a strict reading of your message, that's a deal
 breaker.

Well, not really.
First, like all strict notices, they'd be off by default, so standard
behavior won't change at all from now, and 'type hints' behavior will be
identical to that, so again, nothing new to learn other than the new syntax.
Secondly, if you do enable E_CAST - you may have to slightly *modify* your
understanding of implicit casts, but you won't have to learn two different
sets of rules.  New users will see just one consistent set.

Zeev

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


Andrey Andreev wrote (on 16/07/2014):

I understand that this RFC is about type cast hints and that's fine
with me.


It is and it isn't. It's about a hybrid approach which deliberately 
mixes casting and validation.


Having the mixture alongside pure casts or pure validation is less 
attractive than having the two pure forms side by side, but the 
mixture provides something which can't easily be emulated by either of 
the pure forms.


Therein lies the problem.

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


Zeev Suraski wrote (on 16/07/2014):

Secondly, if you do enable E_CAST - you may have to slightly*modify*  your
understanding of implicit casts, but you won't have to learn two different
sets of rules.  New users will see just one consistent set.


I think I've got a bit lost: I thought you were saying implement the 
concept of a lossless cast, but only emit a warning, not an error.


Wherever and however we use it, we would have to invent a set of rules 
for what lossless cast means, since we don't currently have one.


I'm not sure what two different sets of rules you think other 
proposals would create that this one doesn't.

RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

 -Original Message-
 From: Rowan Collins [mailto:rowan.coll...@gmail.com]
 Sent: Wednesday, July 16, 2014 3:18 PM
 To: internals@lists.php.net
 Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

 Zeev Suraski wrote (on 16/07/2014):
  Secondly, if you do enable E_CAST - you may have to slightly*modify*
  your understanding of implicit casts, but you won't have to learn two
  different sets of rules.  New users will see just one consistent set.

 I think I've got a bit lost: I thought you were saying implement the
 concept of a
 lossless cast, but only emit a warning, not an error.

It's more of a lossy cast, exactly as we have today, that has an
(effectively-optional-since-it's-off-by-default) to warn you about loss of
data.
For the vast majority of users who use the defaults, there'll be nothing new
to learn except for the availability of those implicit casts in function
signatures.
For those who want to take advantage of 'loss protection', they'd have to
learn about this extra warning type and clean their code so that it adheres
to it.  But there too, they'd have consistency, just one set of rules for
implicit cast of scalar values across all of PHP.

 Wherever and however we use it, we would have to invent a set of rules for
 what lossless cast means, since we don't currently have one.

 I'm not sure what two different sets of rules you think other proposals
 would create that this one doesn't.

The proposal currently on the table implements two, simultaneously active
sets of rules that in the long run everyone will have to be aware of.  It
has both the lossy and lossless concepts active in the same time, which
means everyone will have to become familiar with the lossless rules, whether
he's interested in that or not.

Zeev

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


Zeev Suraski wrote (on 16/07/2014):


But there too, they'd have consistency, just one set of rules for
implicit cast of scalar values across all of PHP.


The way I see it is that there's an existing set of rules for the result 
of any cast, implicit or explicit; these are in some cases lossy.


Various proposals here rely on a separate set of rules, which doesn't 
modify the *result* of any casts, but *checks* that the cast will be 
lossless.


The RFC as drafted proposes using these new checks in one specific place 
(function calls when declared with type hints) and with a particular 
outcome (catchable error).


As far as I understand it, you propose defining *the same set of rules*, 
but applying them in a different place (whenever an implicit cast 
occurs) with a different outcome (emit a new E_CAST message).



The proposal currently on the table implements two, simultaneously active
sets of rules that in the long run everyone will have to be aware of.  It
has both the lossy and lossless concepts active in the same time, which
means everyone will have to become familiar with the lossless rules, whether
he's interested in that or not.


Right, so it's not actually about the existence of the rules, just the 
likelihood that someone will be able to ignore them? Someone writing 
code from scratch can, of course, not use any type hints, and so ignore 
the checks either way, but I guess if some project or library adopts 
them, developers will need to learn how they work to interact with that 
project/library.


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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 16 Jul 2014, at 10:29, Zeev Suraski z...@zend.com wrote:

 For me the introduction of a new set of rules is a deal breaker.
 I'm -1 on the RFC the way it is, and +1 if we implement these 'hints' as
 implicit casts, plus change implicit casts to emit E_CAST in case of loss
 of data or 'bogus' conversions.
 
 Why insist E_RECOVERABLE_ERROR and introduce this effectively new set of
 rules, instead of switching to E_CAST and maintain consistency?
 Maintaining consistency is a HUGE deal.  Every such feature we add that
 you need to learn more rules/exceptions for make PHP harder to learn.

As has been pointed out already, that would be inconsistent with existing type 
hints. zend_parse_parameters emits E_WARNING and returns FAILURE, while type 
hints raise E_RECOVERABLE_ERROR. To make scalar type hints not emit 
E_RECOVERABLE_ERROR and instead do something weaker would introduce *more* 
inconsistency, not less.

Also, again, while these new rules aren’t quite the same as zpp’s, they are 
largely the same, and these rules are able to be summed up clearly in a single 
sentence, unlike the confusing and inconsistent zpp rules. We could fix zpp 
later, but that would be harder as it would break backwards-compatibility. And 
again, these new rules only different from zpp in very few places (integral 
values, “123abc” and booleans).
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 16 Jul 2014, at 13:28, Zeev Suraski z...@zend.com wrote:

 It's more of a lossy cast, exactly as we have today, that has an
 (effectively-optional-since-it's-off-by-default) to warn you about loss of
 data.
 For the vast majority of users who use the defaults, there'll be nothing new
 to learn except for the availability of those implicit casts in function
 signatures.
 For those who want to take advantage of 'loss protection', they'd have to
 learn about this extra warning type and clean their code so that it adheres
 to it.  But there too, they'd have consistency, just one set of rules for
 implicit cast of scalar values across all of PHP.

The problem with making this RFC do the lossy thing is it then removes one key 
advantage of it: that this RFC provides a measure of strictness. Without that, 
we have no real compromise proposal, and we might as well introduce a second 
set of “strict” type hints. The whole point of the current behaviour is that it 
compromises between the weak typing and strict typing camps; doing what zpp 
does is giving in to the former camp, and then it’s not a compromise any more, 
is it?
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

Hi!

 As has been pointed out already, that would be inconsistent with
 existing type hints. zend_parse_parameters emits E_WARNING and
 returns FAILURE, while type hints raise E_RECOVERABLE_ERROR. To make
 scalar type hints not emit E_RECOVERABLE_ERROR and instead do
 something weaker would introduce *more* inconsistency, not less.

That's why it is proposed to unify that and always produce E_CAST when
implicit cast makes an iffy decision. As for the mode of failure where
conversion can not be done - we can unify that too. The only reason why
internals produced E_WARNING and not E_ERROR was because we did not have
E_RECOVERABLE_ERROR but in general I see no problem with doing
E_RECOVERABLE_ERROR every time cast can not be made, if it's done in
PHP.next. Usually if you pass something unusable to the function, it's a
sign of serious breakage, and function can not really continue. I don't
see much problem with making it consistent E_RECOVERABLE_ERROR.

 Also, again, while these new rules aren’t quite the same as zpp’s,
 they are largely the same, and these rules are able to be summed up
 clearly in a single sentence, unlike the confusing and inconsistent
 zpp rules. We could fix zpp later, but that would be harder as it
 would break backwards-compatibility. And again, these new rules only
 different from zpp in very few places (integral values, “123abc” and
 booleans). -- Andrea Faulds http://ajf.me/

You say it as if it is an advantage. It is not. Having a rule that is
subtly different in 10% of places is actually worse than having one
totally different, because you start relying on it being the same, and
you don't change your tests to capture the elusive 10%, and everything
works just fine, and then you get in production scenario where data
happens to hit that 10% and your code goes bananas.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 16 Jul 2014, at 20:17, Stas Malyshev smalys...@sugarcrm.com wrote:

 You say it as if it is an advantage. It is not. Having a rule that is
 subtly different in 10% of places is actually worse than having one
 totally different, because you start relying on it being the same, and
 you don't change your tests to capture the elusive 10%, and everything
 works just fine, and then you get in production scenario where data
 happens to hit that 10% and your code goes bananas.

It could cause problems, sure, but it’s worth pointing out that the rules this 
RFC uses are a strict subset of those zpp does; anything this RFC permits will 
be permitted by zpp, it’s the reverse that isn’t necessarily true. If you write 
your code to work with the stricter rules of scalar hints, it’ll work fine for 
internal functions.

At the moment, of course, there’s no scalar type hints for userland functions, 
so it’s already inconsistent.

--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-16 Thread Josh Watzman

On Jul 16, 2014, at 7:03 AM, Andrea Faulds a...@ajf.me wrote:

 On 16 Jul 2014, at 13:28, Zeev Suraski z...@zend.com wrote:
 
 It's more of a lossy cast, exactly as we have today, that has an
 (effectively-optional-since-it's-off-by-default) to warn you about loss of
 data.
 For the vast majority of users who use the defaults, there'll be nothing new
 to learn except for the availability of those implicit casts in function
 signatures.
 For those who want to take advantage of 'loss protection', they'd have to
 learn about this extra warning type and clean their code so that it adheres
 to it.  But there too, they'd have consistency, just one set of rules for
 implicit cast of scalar values across all of PHP.
 
 The problem with making this RFC do the lossy thing is it then removes one 
 key advantage of it: that this RFC provides a measure of strictness. Without 
 that, we have no real compromise proposal, and we might as well introduce a 
 second set of “strict” type hints. The whole point of the current behaviour 
 is that it compromises between the weak typing and strict typing camps; doing 
 what zpp does is giving in to the former camp, and then it’s not a compromise 
 any more, is it?

This is exactly why I really like this proposal. While I love the idea of super 
strict type annotations, I totally understand why they shouldn't be added to 
PHP. The RFC as it stands strikes a great balance between keeping with the PHP 
way of weak typing, while still making scalar type annotations useful.

If I'm writing an app and an API I'm using has been annotated to take an int 
parameter, and I pass something that cannot possibly be an int, I want to know 
that, I want to know it *now*, and I don't want the program to keep executing 
(possibly writing bad data to a database or doing any number of other crazy 
things that could happen when my not-an-int gets converted to an int). The 
entire utility of the type annotation there is that the API developer has said 
I expect an int here, if you don't pass one, you're not using the API 
correctly. As others have argued, the API could technically implement the 
lossless conversion logic itself, but it's fiddly at best to get right, and 
very error-prone. In the other direction, if the API really does want a 
cast-to-int-no-matter-what, it can just omit the type annotation and do that -- 
it's easy and not at all error-prone.

I understand the argument about consistency, but I think this can be mitigated 
if you couch the feature correctly when documenting it, announcing it, etc, so 
that people get the right mental model in their heads when they first hear 
about it. I wouldn't talk about the type annotations this RFC proposes in terms 
of casts, since they aren't really quite casts (as the folks making the 
consistency argument have stated). They're something else -- they're type 
annotations (or type hints, or whatever you want to call them). In that vein, 
they are *consistent* with the existing strict enforcement of object type 
annotations, with the added detail that strict enforcement for scalars is 
defined in terms of lossless conversion as outlined in the RFC, since that's 
the PHP way of loosely dealing with scalar types. The idea of lossless 
conversion has just never been relevant before since there is no such thing as 
a lossless conversion to any object type, or from any type to an array -- but 
it's a completely consistent way of extending the way we deal with the existing 
annotations. (And not inconsistent with casts since it isn't a cast!)

Josh Watzman


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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 15/07/2014 20:44, Andrea Faulds wrote:

PHP has pseudo-functions, maybe we could use that format? cast_int($foo)?

Actually, perhaps the solution is an ahead-of-time check:

 if (safe_cast($foo, int)) {
 $bar = (int!)$foo;
 } else {
 $bar = 1;
 }


I think this would be quite nice - keeps things relatively short without 
introducing so much punctuation that it starts looking like a Perl script ;)


The only problem is that either you need a whole set of functions 
(safe_int($foo), safe_float($foo), etc) or you need some format for that 
second argument, which gets you into some odd meta-validation: if you 
take a string, or an integer (expected to be in the form of a constant 
like PHP_INT), then it would be possible to write safe_cast($foo, $bar), 
and now we need rules on validating $bar, and what happens if it's wrong.


The magic form with a keyword like you've written avoids that, but it 
feels kind of weird - like when SQL date functions take things like 
day and hour as barewords rather than strings.


Maybe I'm overthinking it though.

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 16 Jul 2014, at 20:47, Rowan Collins rowan.coll...@gmail.com wrote:

 I think this would be quite nice - keeps things relatively short without 
 introducing so much punctuation that it starts looking like a Perl script ;)
 
 The only problem is that either you need a whole set of functions 
 (safe_int($foo), safe_float($foo), etc) or you need some format for that 
 second argument, which gets you into some odd meta-validation: if you take a 
 string, or an integer (expected to be in the form of a constant like 
 PHP_INT), then it would be possible to write safe_cast($foo, $bar), and now 
 we need rules on validating $bar, and what happens if it's wrong.
 
 The magic form with a keyword like you've written avoids that, but it feels 
 kind of weird - like when SQL date functions take things like day and 
 hour as barewords rather than strings.

Perhaps this could work?

if (safe_cast((int!)$foobar)) {
$foobar = (int!)$foobar;
} else {
$foobar = 1;
}

With safe_cast() being a pseudo-function à la isset() et al.

I’m not really sure adding a new set of safe casts is really such a good idea; 
we don’t really need (int!) even, we could just have can_cast_int_strict (or 
something like that) given that (int) and (int!) do the same thing for the 
non-failure cases.

And perhaps it’d be better just to leave this to scalar type hints, I’m not 
sure I really want to add this stuff...
--
Andrea Faulds
http://ajf.me/





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

RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

 anything this RFC permits will
 be permitted by zpp, it's the reverse that isn't necessarily true.

Right, so it needs to be fixed.  It makes no sense to force a new agenda
on the language that's inconsistent with the rest of the language.  Align
your new feature to the rest of the language, not the other way around.

Zeev

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 16 Jul 2014, at 21:43, Zeev Suraski z...@zend.com wrote:

 anything this RFC permits will
 be permitted by zpp, it's the reverse that isn't necessarily true.
 
 Right, so it needs to be fixed.  It makes no sense to force a new agenda
 on the language that's inconsistent with the rest of the language.  Align
 your new feature to the rest of the language, not the other way around.

But to do so would be to make the feature less useful, nor satisfy people who 
want stricter hinting.

Argh, we’re going in circles. I should perhaps not continue arguing with you, 
as your position is clear and it’s unlikely to change, and the same is true of 
mine.
--
Andrea Faulds
http://ajf.me/





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

RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

 -Original Message-
 From: Andrea Faulds [mailto:a...@ajf.me]
 Sent: Wednesday, July 16, 2014 11:45 PM
 To: Zeev Suraski
 Cc: Stas Malyshev; Andrey Andreev; Rowan Collins;
internals@lists.php.net
 Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

 On 16 Jul 2014, at 21:43, Zeev Suraski z...@zend.com wrote:

  anything this RFC permits will
  be permitted by zpp, it's the reverse that isn't necessarily true.

  Right, so it needs to be fixed.  It makes no sense to force a new
  agenda on the language that's inconsistent with the rest of the
  language.  Align your new feature to the rest of the language, not the
other
 way around.

 But to do so would be to make the feature less useful, nor satisfy
people who
 want stricter hinting.

Stricter typing does not belong in PHP.  If it did, we'd have it in
internal functions, implicit casting and the rest of the language in
general.  We don't.

And I insist that much like you said people can catch E_RECOVERABLE_ERROR
and turn ignore it, they can do the same with E_CASE - except now they
won't *have* to learn about this new behavior unless they explicitly want
to.  While you think it may not be strict enough for some people, and I
think it'd be too strict for others - the consistency argument should make
the decision between the two obvious.

Also, I tend to agree with Stas that we can consider to do
E_RECOVERABLE_ERROR on the obviously 'bogus' conversions - like array or
object to int.  But E_RECOVERABLE_ERROR on simple data loss is radically
inconsistent with the rest of PHP.

Sorry, I introduced hinting into PHP;  I intentionally did not add typing
for scalars as it goes against the fundamentals of the language, and I
fought this off back in 2008, 2010 and mildly also in 2012.  Call me
persistent :)

FWIW, I think the distance between where you and I stand is not that big -
and if we go in the direction of E_CAST for data loss across the board
(any implicit casts, not just in type hints), and E_RECOVERABLE_ERROR for
completely broken type conversions - this is a big win for PHP, beyond
just type hints.

Zeev

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 16 Jul 2014, at 22:10, Zeev Suraski z...@zend.com wrote:

 Stricter typing does not belong in PHP.  If it did, we'd have it in
 internal functions, implicit casting and the rest of the language in
 general.  We don’t.

This proposal isn’t that much stricter than zpp, aside from booleans I suppose. 
It’s not like we allow literally anything as function arguments for internal 
functions.

 And I insist that much like you said people can catch E_RECOVERABLE_ERROR
 and turn ignore it, they can do the same with E_CASE - except now they
 won't *have* to learn about this new behavior unless they explicitly want
 to.  While you think it may not be strict enough for some people, and I
 think it'd be too strict for others - the consistency argument should make
 the decision between the two obvious.

E_CAST is problematic. Having something we encourage some people to make an 
error and some people not to means that in some cases your library works fine 
and rosy in other people’s environments and sometimes it crashes your app. This 
is *not good*. We must not encourage people to make things errors 
conditionally. It’s either an error or not. I’d veer towards error.

Also, it’s worth pointing out that people will have to learn the new behaviour 
anyway; no matter how we do scalar type hints, we don’t currently have them, 
and once implemented, everyone will have to get used to their existence (and 
probably the fact they will raise E_RECOVERABLE_ERROR).

 Also, I tend to agree with Stas that we can consider to do
 E_RECOVERABLE_ERROR on the obviously 'bogus' conversions - like array or
 object to int.  But E_RECOVERABLE_ERROR on simple data loss is radically
 inconsistent with the rest of PHP.
 
 Sorry, I introduced hinting into PHP;  I intentionally did not add typing
 for scalars as it goes against the fundamentals of the language, and I
 fought this off back in 2008, 2010 and mildly also in 2012.  Call me
 persistent :)
 
 FWIW, I think the distance between where you and I stand is not that big -
 and if we go in the direction of E_CAST for data loss across the board
 (any implicit casts, not just in type hints), and E_RECOVERABLE_ERROR for
 completely broken type conversions - this is a big win for PHP, beyond
 just type hints.

I really don’t like E_CAST for the reasons mentioned above. If it’s a glorified 
E_NOTICE, it’s pointless, if it’s a glorified E_RECOVERABLE_ERROR, you gain 
nothing, and if it’s an error in some environments and not in others, we’ve 
just completely broken our ecosystem.
--
Andrea Faulds
http://ajf.me/





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

RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

 -Original Message-
 From: Andrea Faulds [mailto:a...@ajf.me]
 Sent: Thursday, July 17, 2014 12:17 AM
 To: Zeev Suraski
 Cc: Stas Malyshev; Andrey Andreev; Rowan Collins;
internals@lists.php.net
 Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

 On 16 Jul 2014, at 22:10, Zeev Suraski z...@zend.com wrote:

  Stricter typing does not belong in PHP.  If it did, we'd have it in
  internal functions, implicit casting and the rest of the language in
  general.  We don't.

 This proposal isn't that much stricter than zpp, aside from booleans I
suppose.
 It's not like we allow literally anything as function arguments for
internal
 functions.

We do, mostly.  We accept 42 ,  42 and 42asd as 42.  We accept
1000.17 as 1000 in integer context.
This is a big deal, it's not a minor detail.

  And I insist that much like you said people can catch
  E_RECOVERABLE_ERROR and turn ignore it, they can do the same with
  E_CASE - except now they won't *have* to learn about this new behavior
  unless they explicitly want to.  While you think it may not be strict
  enough for some people, and I think it'd be too strict for others -
  the consistency argument should make the decision between the two
 obvious.

 E_CAST is problematic. Having something we encourage some people to make
 an error and some people not to means that in some cases your library
works
 fine and rosy in other people's environments and sometimes it crashes
your

That's the point.  Many people will not consider this an error, myself
included, and I suspect that also Rasmus and Andi who created the language
concept for the language many many years ago.  PHP doesn't consider it to
be an error today across the language.
Can you explain how a library that works for you won't work for someone
else?

The code inside the library will ALWAYS get valid input, in both options.
Always.  There's no difference.  If it misbehaves, it will be because of
the supplied argument - and it will be clear to the user.  Much like in
most of the cases when an API doesn't work right, it's because it's not
being used correctly and not because of a bug in the implementation.

 Also, it's worth pointing out that people will have to learn the new
behaviour
 anyway; no matter how we do scalar type hints, we don't currently have
them,
 and once implemented, everyone will have to get used to their existence
(and
 probably the fact they will raise E_RECOVERABLE_ERROR).

Of course they'd have to learn something new - the new syntax at the very
least.  But they wouldn't have to learn something new and inconsistent.

  Also, I tend to agree with Stas that we can consider to do
  E_RECOVERABLE_ERROR on the obviously 'bogus' conversions - like array
  or object to int.  But E_RECOVERABLE_ERROR on simple data loss is
  radically inconsistent with the rest of PHP.

  Sorry, I introduced hinting into PHP;  I intentionally did not add
  typing for scalars as it goes against the fundamentals of the
  language, and I fought this off back in 2008, 2010 and mildly also in
  2012.  Call me persistent :)

  FWIW, I think the distance between where you and I stand is not that
  big - and if we go in the direction of E_CAST for data loss across the
  board (any implicit casts, not just in type hints), and
  E_RECOVERABLE_ERROR for completely broken type conversions - this is a
  big win for PHP, beyond just type hints.

 I really don't like E_CAST for the reasons mentioned above. If it's a
glorified
 E_NOTICE, it's pointless,

It's not, not at all.  It helps you clean your code from these issues *IF*
you care about them, and it doesn't bug others who don't.  E_NOTICE's and
E_STRICT work remarkably well - I know many people who choose to ignore
them, and many people who wouldn't deploy code before it's 100% clean of
them.  While I'm sure you have an opinion on what this setting should be
(and I might even be able to guess it), PHP's philosophy was letting the
users (developers) choose.

Ultimately it seems you dislike a very fundamental concept in PHP, that
scalar types are 'transient' and can convert without notice depending on
the context.  You also don't seem to be too fond of the 'notice/strict'
type errors :)  I can understand that, but nonetheless, the former is a
very basic fundamental part of PHP and we shouldn't add features that go
against it, and the latter is a concept that's been serving us well for
years.

Zeev

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 16 Jul 2014, at 22:42, Zeev Suraski z...@zend.com wrote:

 That's the point.  Many people will not consider this an error, myself
 included, and I suspect that also Rasmus and Andi who created the language
 concept for the language many many years ago.  PHP doesn't consider it to
 be an error today across the language.
 Can you explain how a library that works for you won't work for someone
 else?

Someone relies on E_CAST not being fatal. Someone wanting strictness makes an 
error handler making it fatal. Bam, an awful lot of code breaks. E_CAST is a 
terrible idea if we want software interoperability. We can’t have it both ways; 
type hints must be either strict or not strict, if they’re conditionally strict 
by environment then we will destroy our ecosystem.

Of course, we could just make it a glorified E_NOTICE, but then what’s the 
point? E_NOTICE already exists.

 The code inside the library will ALWAYS get valid input, in both options.
 Always.  There's no difference.  If it misbehaves, it will be because of
 the supplied argument - and it will be clear to the user.  Much like in
 most of the cases when an API doesn't work right, it's because it's not
 being used correctly and not because of a bug in the implementation.

Right. The code inside the library will, sure. The point is that the library 
will now crash the program because it wasn’t written with a 
strictly-interpreted E_CAST in mind.

 Of course they'd have to learn something new - the new syntax at the very
 least.  But they wouldn't have to learn something new and inconsistent.

It’s inconsistent anyway. Type hints don’t act like zpp does, unless you want 
me to make them emit E_WARNING and return NULL.

 It's not, not at all.  It helps you clean your code from these issues *IF*
 you care about them, and it doesn't bug others who don't.  E_NOTICE's and
 E_STRICT work remarkably well - I know many people who choose to ignore
 them, and many people who wouldn't deploy code before it's 100% clean of
 them.  While I'm sure you have an opinion on what this setting should be
 (and I might even be able to guess it), PHP's philosophy was letting the
 users (developers) choose.

As I’ve explained earlier, letting them choose to make this fatal would be a 
horrible, horrible idea.

 Ultimately it seems you dislike a very fundamental concept in PHP, that
 scalar types are 'transient' and can convert without notice depending on
 the context.

Nope, I have zero problem with this basic feature. I may have in the past, 
sure, but I have come to like PHP’s weak typing.

Also, they *don’t* universally convert without notice, they only do when they 
fit a certain set of conditions. This RFC just makes userland type hints (which 
much of the community apparently wants to be fully strict?) have a slightly 
tighter ruleset that’s more logical, if somewhat inconsistent with the rest of 
PHP.

 You also don't seem to be too fond of the 'notice/strict'
 type errors :)

E_NOTICE makes sense, I just don’t think it’s the right approach for type hints.

(Though speaking of which, the default object casting handler’s behaviour of 
just emitting a notice instead of actually failing is really weird. Why is that 
an E_NOTICE? What on earth is the failure case for, then? Surely it’s the 
caller’s job to emit the notice?)

 I can understand that, but nonetheless, the former is a
 very basic fundamental part of PHP and we shouldn't add features that go
 against it, and the latter is a concept that's been serving us well for
 years.

This is obviously a matter of opinion, but I really don’t think this RFC goes 
against that. This RFC encourages automatic type conversion, it’s just slightly 
less lenient than zpp is to help write less buggy software. I suppose it fits 
the existing mould, where internal functions are really tolerant and won’t make 
much fuss (a mere E_WARNING and NULL) while userland type hints are much more 
draconian.
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-16 Thread Lester Caine

On 16/07/14 23:12, Andrea Faulds wrote:
 As I’ve explained earlier, letting them choose to make this fatal would be a 
 horrible, horrible idea.

This is no worse than the current mess created by E_STRICT ... we wither
have to spend days reworking the code to respect E_STRICT ... or we
switch it off. For legacy systems it simply HAS to be switched off and
on the whole the code works.

I'm with Zeev that the default at this point in time should be 'off'
which is what E_CAST provides. I can understand your concern over third
party libraries forcing it on - we have exactly the same arogance with
E_STRICT - so we need at least a litle cooperation, rather than someone
dictating that a new way of working is the only way ofrward.

-- 
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 16 Jul 2014, at 23:45, Lester Caine les...@lsces.co.uk wrote:

 On 16/07/14 23:12, Andrea Faulds wrote:
 As I’ve explained earlier, letting them choose to make this fatal would be a 
 horrible, horrible idea.
 
 This is no worse than the current mess created by E_STRICT ... we wither
 have to spend days reworking the code to respect E_STRICT ... or we
 switch it off. For legacy systems it simply HAS to be switched off and
 on the whole the code works.

You know, I’ve never asked you this before: why don’t you just turn off 
E_STRICT?
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

Hi!

 The problem with making this RFC do the lossy thing is it then
 removes one key advantage of it: that this RFC provides a measure of
 strictness. Without that, we have no real compromise proposal, and we
 might as well introduce a second set of “strict” type hints. The
 whole point of the current behaviour is that it compromises between
 the weak typing and strict typing camps; doing what zpp does is
 giving in to the former camp, and then it’s not a compromise any
 more, is it?

I think if the compromise is having multiple set of rules for implicit
casts then this compromise is not worth it. If you answer to the
question of what happens if I use a string in boolean context with
well, it depends, if it's boolean context in syntax construct, it's one
rule, if it's internal function, another, if it's user function, yet
another - it's not a good compromise. Any solution where you can give
an actual answer like empty string is false, all others are true is
much better. I'm not a fan of strict types in PHP, but having
inconsistent rules is IMO so bad that even strict types would be better.
At least you'd then know on which planet you are.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 16/07/2014 23:12, Andrea Faulds wrote:

Of course, we could just make it a glorified E_NOTICE, but then what’s the 
point? E_NOTICE already exists.


I just realised something that's made me really confused about this 
whole debate: internal functions already emit E_NOTICE for *exactly* the 
case we're discussing!


Maybe this was obvious to the rest of you, but this:

date('d', '123abc');

gives this:

Notice: A non well formed numeric value encountered


So, we already have a notion of what casts are well formed and what 
aren't! Clearly, I've been running with notices suppressed for too long, 
or I'd have realised this sooner, and I think I've been talking at 
cross-purposes with Zeev and others because nobody had directly 
mentioned this.



Now, I have no idea how ZPP actually works, and get lost in a maze of 
macros whenever I try to look at it, but evidently it has logic to 
distinguish, at least for string-int, three cases:


1) safe / lossless / well formed input (cast silently), e.g. '123' = 
int(123)
2) unsafe / lossy / non well formed (give a notice), 'e.g. '123abc' = 
int(123)
3) impossible / inappropriate (from the point of view of the user, give 
a warning, and cause different behaviour of the function), e.g. 'abc' = int


Note that this is completely different from implicit casts, which have 
also been mentioned a lot, since those perform no validation at all 
(e.g. 'abc' + 'def' will happily give you int(0)). [Or that's what I 
think of when someone says implicit cast, anyway; I think it's what 
the manual calls type juggling.]



So what are we actually talking about with Andrea's (/ Anthony's) 
current RFC / patch?


Firstly, as I understand it, the current proposal treats both category 2 
and 3 as errors, in the context of userland typehints. Is there a 
compromise possible where only category 3 is treated as an error, and 2 
as a warning? Or some other position which keeps them distinct, but 
detects both, as internal functions appear to do?


Secondly, there is mention of cases where the categorisation differs. 
I'm not really clear what those actually are.



So, my apologies for being slow on the uptake, but given the mix of 
people extremely familiar with the core, and people familiar only with 
its effects on userland, I wonder if I'm not the only one.


Humble regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

Hi!

 E_CAST is problematic. Having something we encourage some people to
 make an error and some people not to means that in some cases your
 library works fine and rosy in other people’s environments and
 sometimes it crashes your app. This is *not good*. We must not
 encourage people to make things errors conditionally. It’s either an
 error or not. I’d veer towards error.

I think this is not correct. It can be OK in one context and error in
another. I.e., if you say let's ask users how many gizmos they want
and the user gives 1  (note the space) and we tell them we don't know
what this even means, there's an extra character there - doing this
would just annoy the user. Silently converting it to 1 would do the
right thing.

If you say making any distinction between 1 and 1  is useless for
you - well, I can accept that. I can see use cases where it makes sense
to make distinction but they are a minority. I think there's a level
between E_RECOVERABLE_ERROR and silence where it's not I can't make any
sense out of this garbage but also not it's clean data. But I can
also live without this level, if that is what the majority comes to. In
that case, I'd rather have 1  converted to 1 silently.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 17 Jul 2014, at 00:12, Stas Malyshev smalys...@sugarcrm.com wrote:

 I think if the compromise is having multiple set of rules for implicit
 casts then this compromise is not worth it. If you answer to the
 question of what happens if I use a string in boolean context with
 well, it depends, if it's boolean context in syntax construct, it's one
 rule, if it's internal function, another, if it's user function, yet
 another - it's not a good compromise. Any solution where you can give
 an actual answer like empty string is false, all others are true is
 much better. I'm not a fan of strict types in PHP, but having
 inconsistent rules is IMO so bad that even strict types would be better.
 At least you'd then know on which planet you are.

To be fair, the RFC as it stands has booleans be strict, with true and false 
the only allowed values. Also, strings, integers and floats have (IMO) 
easy-to-explain rules under this RFC.:

* bools: bools and objects that convert to bools only
* strings: Anything that can be losslessly converted to a string works (any 
int, float, string, or object with toString)
* float: Anything that can be losslessly converted to a float (any int, float, 
numeric-only string, or object that converts to float)
* int: Anything that can be losslessly converted to an int (any int, float 
that’s integral, integral numeric-only string, or object that converts to int)

Actually, objects are a special case here, unfortunately, but I didn’t really 
have a choice because they cast weirdly.

This compares to the current zpp rules (as well as I can remember them, anyway):

* bools: Any int, string, float, bool, or object that can cast to bool; if it’s 
an int, then non-zero is true; if it’s a float, then non-zero is true; if it’s 
a string, then it’s true unless it’s an empty string or zero
* strings: Anything, unless it’s an object that doesn’t implement toString (I 
think that’s the rule, anyway)
* int: Any int, float, bool, object that casts to int, or string that begins 
with numeric digits (this is sometimes a notice)
* float: Any int, float, bool, object that casts to float, or string that 
begins with float-like digits (this is sometimes a notice)

However, I honestly can’t remember zpp’s exact behaviour and I might have made 
some mistakes there.

Is zend_parse_parameters’s behaviour actually documented in the manual? A quick 
search finds nothing.

--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 17 Jul 2014, at 00:18, Rowan Collins rowan.coll...@gmail.com wrote:

 Now, I have no idea how ZPP actually works, and get lost in a maze of macros 
 whenever I try to look at it, but evidently it has logic to distinguish, at 
 least for string-int, three cases:
 
 1) safe / lossless / well formed input (cast silently), e.g. '123' = int(123)
 2) unsafe / lossy / non well formed (give a notice), 'e.g. '123abc' = 
 int(123)
 3) impossible / inappropriate (from the point of view of the user, give a 
 warning, and cause different behaviour of the function), e.g. 'abc' = int

zpp’s casts are (one form of) implicit cast. We actually do multiple different 
kinds of implicit casts in different places with different results; “0xa” is 
variously an integer and not an integer, depending on context, because nobody 
seems to have made their mind up whether is_numeric_string or strtol is used to 
parse numeric strings. :(

The only casts that are explicit are using (int) and friends, or intval() and 
friends (I believe the two are equivalent).

--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 17 Jul 2014, at 00:23, Stas Malyshev smalys...@sugarcrm.com wrote:

 I think this is not correct. It can be OK in one context and error in
 another. I.e., if you say let's ask users how many gizmos they want
 and the user gives 1  (note the space) and we tell them we don't know
 what this even means, there's an extra character there - doing this
 would just annoy the user. Silently converting it to 1 would do the
 right thing.
 
 If you say making any distinction between 1 and 1  is useless for
 you - well, I can accept that. I can see use cases where it makes sense
 to make distinction but they are a minority. I think there's a level
 between E_RECOVERABLE_ERROR and silence where it's not I can't make any
 sense out of this garbage but also not it's clean data. But I can
 also live without this level, if that is what the majority comes to. In
 that case, I'd rather have 1  converted to 1 silently.

There are really only two levels of error IMO, those that are log file messages 
(silenced or no), and those that actually stop the script unless handled. I 
worry about making E_CAST the former but allowing people to make it the latter, 
because then people would and suddenly code relying on it being the former 
would make your app stop working.

--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)


On 17/07/2014 00:35, Andrea Faulds wrote:

zpp’s casts are (one form of) implicit cast. We actually do multiple different 
kinds of implicit casts in different places with different results; “0xa” is 
variously an integer and not an integer, depending on context, because nobody 
seems to have made their mind up whether is_numeric_string or strtol is used to 
parse numeric strings. :(


Well, that just makes me more confused why the word consistency 
appears so much in this thread.


Zeev, Stas, could you reference the set of rules which you think type 
hints should be consistent with?


--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-16 Thread Lester Caine

On 16/07/14 23:47, Andrea Faulds wrote:
 This is no worse than the current mess created by E_STRICT ... we wither
  have to spend days reworking the code to respect E_STRICT ... or we
  switch it off. For legacy systems it simply HAS to be switched off and
  on the whole the code works.
 You know, I’ve never asked you this before: why don’t you just turn off 
 E_STRICT?

Because it depends on the security status of third party libraries! All
these bright ideas look good in isolation, but there is a much bigger
picture to address, with perhaps a large percentage of systems still
using legacy code. If I DON'T upgrade the code, then moving onto newer
servers gets even more difficult. If there was unlimited time, then it
would be possible to upgrade the remaining 5.2 systems to 5.3, tidy up
so they can move on to 5.4, and then test out on 5.5. I'm working
between 5.2 and 5.4 at the moment but I'm looking at all that is going
on and wondering how much more work will be required once I have finally
killed off the 5.2 sites! It would help if I could reliably retain the
correct versions of third party libraries, but often that is not possible.

-- 
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

Hi!

 There are really only two levels of error IMO, those that are log
 file messages (silenced or no), and those that actually stop the
 script unless handled. I worry about making E_CAST the former but
 allowing people to make it the latter, because then people would and
 suddenly code relying on it being the former would make your app stop
 working.

This is already a possibility. You can turn E_NOTICE or E_STRICT into a
fatal error by using error handlers. In fact, phpunit does it all the
time, turning errors into exceptions. So are you saying other error
levels are worthless too because libraries can work with one set of
error handlers and fail with another?

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-15 Thread Derick Rethans

On Mon, 14 Jul 2014, Stas Malyshev wrote:

  In general, I am not in favour of casting typehints, as it would be 
  a different behaviour from the hard-check typehints that we already 
  have for classes and arrays.
 
 It already is. All internal functions behave this way.

But casting typehints is a userland feature, not an internal function.

cheers,
Derick

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-15 Thread Derick Rethans

On Mon, 14 Jul 2014, Rowan Collins wrote:

 Derick Rethans wrote (on 14/07/2014):
  A compromise by adding more inconsistencies.
 
 The only way of not introducing some inconsistencies (or, to put it another
 way, new features) is to use strict type hints, which perform no casting, and
 error on invalid input, since that's what the existing type hints do, in
 particular array. There's broad consensus that that wouldn't be very
 PHP-ish, and it has been rejected in previous discussions.

I am quite aware of that.

 Here are the main variants discussed in this thread:
 
 1) add type hints using existing syntax, but which are actually silent casts,
 rather than the strict validation performed for existing types

 2) add type hints using existing syntax, which are casts, but also act
 differently from existing casts by emitting some kind of notice

 3) add cast hints using a new syntax

 4) add type hints using existing syntax, which use a new lossless cast, i.e.
 perform validation for completely wrong input ('abc' as an int param) but
 allow juggling for reasonable input ('123' as an int param).
 
 Option 2 (or 3) could also be implemented by making *all* lossy casts emit
 some kind of notice.
 
 This RFC currently proposes option 4.

Yes. And with that option I have a problem, as nothing else does it like 
that now - hence my arguing against a new set of casting rules. Option 
1 is equivalent to my argument that this should be equivalent:

function foo(int $var) {} 

function foo($var) { $var = (int) $var; } 

and called by f.e.:

foo('123abc');

cheers,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

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

RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-15 Thread Zeev Suraski

 -Original Message-
 From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
 Sent: Tuesday, July 15, 2014 2:00 AM
 To: Andrea Faulds; Chris Wright
 Cc: PHP internals
 Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

 Hi!

  I suggested on IRC that empty strings, TRUE, FALSE, NULL, and values
  that validate for the int type hint could be accepted. Is that a good
  idea? Though it feels a bit loose, I think it covers all the important
  common use cases.

 Then you need to make all internal functions that accept bool work this
 way
 too. But I'm not sure why you need this. You accept that if(foo) works.
 Then
 why function foo(bool $x) { if($x) { ...  should work differently? Yes,
 it is an
 edge case and bad code style. So are many other legal constructs. In my
 opinion, it is better to permit edge cases and be consistent than try to
 carve
 out perfect set of what can be boolean and get lost in the maze of
 exceptions and conditions. E.g. if we say we treat 1 and 1 mostly the
 same,
 then we should say unless we convert them to bool in a context of a
 function
 call where they are not. I think it should be kept simpler - if we accept
 foo
 in boolean context, then we should just accept it.

Exactly.

Zeev

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

RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-15 Thread Ford, Mike

Oh, goodness, deary me -- this sounded so familiar I just had to do some 
delving and hey presto! I refer you to: 
http://marc.info/?l=php-internalsm=124655821522388

(...which, interestingly, even predates Zeev's 2010 claim, and I believe may 
have taken inspiration from yet earlier suggestions back around 2006!!)


--
Mike Ford, Electronic Information Developer, Libraries and Learning Innovation
Leeds Metropolitan University, 403a Sheila Silver Library, Leslie Silver 
Building, City Campus, Leeds LS1 3ES, United Kingdom
Tel: +44 113 812 4730 | Email: m.f...@leedsmet.ac.uk



 -Original Message-
 From: Jocelyn Fournier [mailto:jocelyn.fourn...@gmail.com]
 Sent: 14 July 2014 14:30
 To: n...@devilix.net
 Cc: internals@lists.php.net; indey...@gmail.com; Andrea Faulds
 Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-
 opening)

 Hi,

 Le 14/07/2014 15:19, Andrey Andreev a écrit :
  Hi,
 
  On Mon, Jul 14, 2014 at 4:12 PM, Alexey Zakhlestin
 indey...@gmail.com wrote:
  Some people talk about inconsistency, which is introduced by
 reusing same syntax for strict parameter types and scalar
 parameter casts”. There’s some truth there.
  Let’s use different syntax.
 
  This might work:
 
   function foo((int) $a)
   {
   var_dump($a);
   }
 
  I would read it as declaration-level casting
 
  I strongly support this.
 
  What we currently have with class/array typing is a different
 behavior
  (regardless of the details behind it), and this syntax would make
 that
  noticeable, which is a great thing.

 Actually both syntax could exists :

 function foo((int) $a)
 {

 = scalar parameter casts syntax


 function foo(int $a)
 {

 = strict type checking syntax (consistant with array / class
 syntax)


 I like this approach as well.


Jocelyn

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





From 22 September 2014 Leeds Metropolitan University will become Leeds Beckett 
University.
Find out more at http://www.leedsbeckett.ac.uk
To view the terms under which this email is distributed, please go to:-
http://www.leedsmet.ac.uk/email-disclaimer.htm

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

On Mon, Jul 14, 2014 at 7:19 PM, Kristopher kristopherwil...@gmail.com
wrote:

 On Mon, Jul 14, 2014 at 1:14 PM, Alain Williams a...@phcomp.co.uk wrote:

  On Mon, Jul 14, 2014 at 06:09:22PM +0100, Andrea Faulds wrote:
  
   On 14 Jul 2014, at 18:01, Alain Williams a...@phcomp.co.uk wrote:
  
But if you have:
   
   function foo(int $a) {
   ...
$a = 3 / 2;
   }
   
What do you expect $a to contain ? I would suggest integer 1.
  
 
 I would have expected 1 - since it appears, from the code, that $a should
  only contain integers.


 What about the current type hinting we have, then?

 function foo(Bar $a) {
 $a = 3 / 2;
 }

 Perfectly OK. Why would we treat scalars any different?


this was asked and answered a dozen of times in the past, but let me repeat
once again:

php does support type juggling/coercion for scalar types, but not for
complex types.
introducing strict typehints for complex types was safe, as there are no
expectation from the users, if you expect an instance of Foo and you got a
Bar (which isn't a subclass of Foo) then you know that you screwed up.
(personally I think that the adding the support for array to the strict
typehints was a bad idea, but that is out of scope here.)
But people do have expectations about the scalar types in php, and they
used to not care about the exact types of a variable as long as it can be
coerced into the expected type.
If you think it over, probably 80-90%+ of all incoming data we are working
with coming from a source which delivers everything as a string (anything
coming from HTTP is a string, anything coming from the database which isn't
using a binary protocol arrives as string, anything coming from memcached
is a string, redis: same thing).
But php doesn't care, because one of it's distinguished features is that it
can coerce between scalar types.
If we introduce scalar type hints, people will use it, if they will use it,
people have to be aware that they can't pass numeric looking strings into
functions and expect them to work.
It will blow up with a fat E_RECOVERABLE_ERROR.
But this won't hold back the library authors from using it, which means
that the consumers of those libs has to start coding defensively, and make
sure that the variable holding the value 123 is an integer and not a float
or a string, because that will blow up something.
And we can argue whether or not it is a good thing that php has type
juggling, but we have that, and it is not likely to be changed(biggest BC
break ever), so introducing something which completelly negates that won't
likely to get support from the devs.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

On Tue, Jul 15, 2014 at 2:19 PM, Ferenc Kovacs tyr...@gmail.com wrote:




 On Mon, Jul 14, 2014 at 7:19 PM, Kristopher kristopherwil...@gmail.com
 wrote:

 On Mon, Jul 14, 2014 at 1:14 PM, Alain Williams a...@phcomp.co.uk
 wrote:

  On Mon, Jul 14, 2014 at 06:09:22PM +0100, Andrea Faulds wrote:
  
   On 14 Jul 2014, at 18:01, Alain Williams a...@phcomp.co.uk wrote:
  
But if you have:
   
   function foo(int $a) {
   ...
$a = 3 / 2;
   }
   
What do you expect $a to contain ? I would suggest integer 1.
  
 
 I would have expected 1 - since it appears, from the code, that $a should
  only contain integers.


 What about the current type hinting we have, then?

 function foo(Bar $a) {
 $a = 3 / 2;
 }

 Perfectly OK. Why would we treat scalars any different?


 this was asked and answered a dozen of times in the past, but let me
 repeat once again:

 php does support type juggling/coercion for scalar types, but not for
 complex types.
 introducing strict typehints for complex types was safe, as there are no
 expectation from the users, if you expect an instance of Foo and you got a
 Bar (which isn't a subclass of Foo) then you know that you screwed up.
 (personally I think that the adding the support for array to the strict
 typehints was a bad idea, but that is out of scope here.)
 But people do have expectations about the scalar types in php, and they
 used to not care about the exact types of a variable as long as it can be
 coerced into the expected type.
 If you think it over, probably 80-90%+ of all incoming data we are working
 with coming from a source which delivers everything as a string (anything
 coming from HTTP is a string, anything coming from the database which isn't
 using a binary protocol arrives as string, anything coming from memcached
 is a string, redis: same thing).
 But php doesn't care, because one of it's distinguished features is that
 it can coerce between scalar types.
 If we introduce scalar type hints, people will use it, if they will use
 it, people have to be aware that they can't pass numeric looking strings
 into functions and expect them to work.
 It will blow up with a fat E_RECOVERABLE_ERROR.
 But this won't hold back the library authors from using it, which means
 that the consumers of those libs has to start coding defensively, and make
 sure that the variable holding the value 123 is an integer and not a float
 or a string, because that will blow up something.
 And we can argue whether or not it is a good thing that php has type
 juggling, but we have that, and it is not likely to be changed(biggest BC
 break ever), so introducing something which completelly negates that won't
 likely to get support from the devs.

 --
 Ferenc Kovács
 @Tyr43l - http://tyrael.hu


sorry, not neccessary the best place for my reply, I just had to type that
out seeing the dozens of mails from the last couple of days.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-15 Thread Alain Williams

On Tue, Jul 15, 2014 at 02:19:46PM +0200, Ferenc Kovacs wrote:

But php doesn't care, because one of it's distinguished features is that it
can coerce between scalar types.

Yes: and you will still be able to do that. No one will take that away, so
continue to use that where it is appropriate.

If we introduce scalar type hints, people will use it, if they will use it,
people have to be aware that they can't pass numeric looking strings into
functions and expect them to work.

All input from a form needs to be validated before use; failure to do that is,
unfortunately, common and leads to issues. If this helps remind people to do so
then it can only be good.

The first listed here is ' Improper input validation':

http://www.softwaretestinghelp.com/top-25-common-programming-bugs-every-tester-should-know/

It will blow up with a fat E_RECOVERABLE_ERROR.
But this won't hold back the library authors from using it, which means
that the consumers of those libs has to start coding defensively, and make
sure that the variable holding the value 123 is an integer and not a float
or a string, because that will blow up something.

They will have it blow up when it first runs, fix the bug (add a cast or
something) and move on. I think that it is an insult to PHP coders to assume
that they will not be able to cope. They will scratch their heads the first time
that it happens to them, google/... learn.

The benefit of this is fewer issues in libraries. It may also help by catching
user/coder errors earlier and so make their life easier.

There is trade off bet

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
#include std_disclaimer.h

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-15 Thread Andrea Faulds


On 15 Jul 2014, at 13:50, Alain Williams a...@phcomp.co.uk wrote:

 It will blow up with a fat E_RECOVERABLE_ERROR.
 But this won't hold back the library authors from using it, which means
 that the consumers of those libs has to start coding defensively, and make
 sure that the variable holding the value 123 is an integer and not a float
 or a string, because that will blow up something.
 
 They will have it blow up when it first runs, fix the bug (add a cast or
 something) and move on. I think that it is an insult to PHP coders to assume
 that they will not be able to cope. They will scratch their heads the first 
 time
 that it happens to them, google/...  learn.
 
 The benefit of this is fewer issues in libraries. It may also help by catching
 user/coder errors earlier and so make their life easier.
 
 There is trade off bet

As has been pointed out previously, this isn’t good. People will simply do this 
just to fix an error:

foobar((int)$_GET[‘thing’]);

However, an explicit cast can *never fail*. It will always return something, 
whether it makes sense or not. This is simply going to lead to buggy software.

On the other hand, this RFC proposes a set of type hint casts which have 
stricter rules than an explicit cast, and also somewhat stricter than 
zend_parse_parameters, meaning that people can safely do $_GET[‘thing’] and 
it’ll work, but if a nonsensical value is passed in, the program will error as 
it should.
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

On Tue, Jul 15, 2014 at 2:50 PM, Alain Williams a...@phcomp.co.uk wrote:

On Tue, Jul 15, 2014 at 02:19:46PM +0200, Ferenc Kovacs wrote:

But php doesn't care, because one of it's distinguished features is that
it
can coerce between scalar types.

Yes: and you will still be able to do that. No one will take that away, so
continue to use that where it is appropriate.

you can't optionally introduce strict typing to php, as the two of them
can't co-exists.
nobody forces you to not use a language with strict typing if you want
that, but I don't think that it would worth changing the php type system at
this point.

If we introduce scalar type hints, people will use it, if they will use
it,
people have to be aware that they can't pass numeric looking strings into
functions and expect them to work.

All input from a form needs to be validated before use; failure to do that
is,
unfortunately, common and leads to issues. If this helps remind people to
do so
then it can only be good.

the value needs to be validated, nobody argues that.
but enforcing the types where they are otherwise interchangeable doesn't
really provide any additional protection as far as I'm concerned.
it would only introduce mandatory boilerplate code where you cast your
integers to float or strings to int so that some function deep down in the
execution graph doesn't blow up before doing any sort of proper value
validation.

The first listed here is ' Improper input validation':

http://www.softwaretestinghelp.com/top-25-common-programming-bugs-every-tester-should-know/

as I mentioned above, nobody argues that input validation (and escaping
output in a context sensitive manner) is a must.
(btw. if you are interested in the topic I would suggest checkout out the
OWASP project and the top10 list especially)

It will blow up with a fat E_RECOVERABLE_ERROR.
But this won't hold back the library authors from using it, which means
that the consumers of those libs has to start coding defensively, and
make
sure that the variable holding the value 123 is an integer and not a
float
or a string, because that will blow up something.

They will have it blow up when it first runs, fix the bug (add a cast or
something) and move on. I think that it is an insult to PHP coders to
assume
that they will not be able to cope.

we had smaller BC breaks delaying the adoption of a new version with years.
as I said in my previous email, we can talk about it, but it is unlikely to
happen.

They will scratch their heads the first time
that it happens to them, google/... learn.

yeah, and they

The benefit of this is fewer issues in libraries. It may also help by
catching
user/coder errors earlier and so make their life easier.

it is already possible with the current status (just needs more boilerplate
code in the library), and it will be much more easier with the proposed
casting typehints.
as you are probably aware the typehint proposed in this rfc will also error
out when the casting would cause data loss.

There is trade off bet

yeah, I just think that the gain(I don't see any) over the currently
proposed RFC doesn't worth the cost (which I consider huge).

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-15 Thread Andrea Faulds


On 15 Jul 2014, at 14:18, Ferenc Kovacs tyr...@gmail.com wrote:

 you can't optionally introduce strict typing to php, as the two of them
 can't co-exists.
 nobody forces you to not use a language with strict typing if you want
 that, but I don't think that it would worth changing the php type system at
 this point.

It’s also worth noting that if you do want strict typing in PHP, you now have 
an alternative: Hack. Hack even allows you to mix strictly-typed code with 
non-strictly-typed code if you want. But PHP is not going to go in that 
direction. This RFC offer rather strict validation of input to a function, but 
it does not offer strict *typing*, as strings and floats, where 
interchangeable, are accepted.

 as I mentioned above, nobody argues that input validation (and escaping
 output in a context sensitive manner) is a must.

Isn’t a must, surely? (I assume that was a typo)

--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

On Tue, Jul 15, 2014 at 3:21 PM, Andrea Faulds a...@ajf.me wrote:


 On 15 Jul 2014, at 14:18, Ferenc Kovacs tyr...@gmail.com wrote:

  you can't optionally introduce strict typing to php, as the two of them
  can't co-exists.
  nobody forces you to not use a language with strict typing if you want
  that, but I don't think that it would worth changing the php type system
 at
  this point.

 It’s also worth noting that if you do want strict typing in PHP, you now
 have an alternative: Hack. Hack even allows you to mix strictly-typed code
 with non-strictly-typed code if you want.


even Hack has some gotchas:
http://grokbase.com/t/php/php-internals/1459q785wg/rfc-return-type-declarations-pre-vote-follow-up#20140509j1db9b91d2642wzbzbgte7k450


But PHP is not going to go in that direction. This RFC offer rather strict
 validation of input to a function, but it does not offer strict *typing*,
 as strings and floats, where interchangeable, are accepted.


yep



  as I mentioned above, nobody argues that input validation (and escaping
  output in a context sensitive manner) is a must.

 Isn’t a must, surely? (I assume that was a typo)


I wasn't talking about the rfc or the typehints, but having proper input
validation in your application in general.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)

2014-07-15 Thread Rowan Collins


Ferenc Kovacs wrote (on 15/07/2014):

On Tue, Jul 15, 2014 at 3:21 PM, Andrea Faulds a...@ajf.me wrote:


as I mentioned above, nobody argues that input validation (and escaping
output in a context sensitive manner) is a must.

Isn’t a must, surely? (I assume that was a typo)


I wasn't talking about the rfc or the typehints, but having proper input
validation in your application in general.



I think it was just sloppy grammar: you wrote nobody argues that ... is 
a must but meant nobody argues that ... isn't a must, or nobody 
argues against ... being a must; or perhaps nobody disagrees that ... 
is a must / everybody agrees that ... is a must.


:)

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

Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)