date:20140715


On 15 Jul 2014, at 03:31, Bishop Bettini bis...@php.net wrote:
 I need some education.  Can you elaborate on the specific situations where 
 integer division would be used without other functions from bcmath or gmp?
 
 I see in the RFC you mention seconds to hh:mm and index to rows/cols, but can 
 you give some actual before and after samples?  Like this is how it would 
 be done today without intdiv, and here's how it would be done after?

Sure. Say I have a number of seconds which I wish to split into years, days, 
hours, minutes and seconds, for example:

$s = 100;
$seconds = $s % 60;
$minutes = intdiv($s, 60) % 60;
$hours = intdiv($s, 3600) % 24;
$days = intdiv($s, 3600 * 24) % 365;
$years = intdiv($s, 3600 * 24 * 365);

Currently, you’d have to cheat and use floating-point division:

$x = 100;
$seconds = $s % 60;
$minutes = (int)($s / 60) % 60;
$hours = (int)($s / 3600) % 24;
$days = (int)($s / (3600 * 24)) % 365;
$years = (int)($s / (3600 * 24 * 365));

The second one is a bit of a hack, really, but it would probably work most of 
the time since realistically nobody is using 53-bit time values at the moment 
(though people are using 32-bit values, so that 64-bit RFC can’t come soon 
enough given Y2K38).

However, intdiv() is perhaps not the best way to implement it or the best 
syntax.

--
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-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] intdiv()


On 15 Jul 2014, at 06:50, Kris Craig kris.cr...@gmail.com wrote:

 While a practical argument can certainly be made that existing solutions can 
 fit the examples OP cited, I don't think that takes away from the underlying 
 principle of the argument:  That there's no reason *not* to include a basic 
 integer division in PHP.  It's never made sense to me why it wasn't included. 
  Rather than an intdiv() function, though, I wonder if an operator would be a 
 better approach.  Some languages I've seen that use / as the division 
 operator will use a \ as the integer division operator.

We use \ for namespaces, and Python 3’s // obviously can’t be used, so I might 
suggest Pascal’s div operator:

$minutes = ($s div 60) % 60;

Failing that, div() as a built-in function much like pow() is:

$minutes = div($s, 60) % 60;
--
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] intdiv()


On 15 Jul 2014, at 08:06, Lester Caine les...@lsces.co.uk wrote:

 Taking this in isolation is wrong ...
 It is essentially linked up with all of the discussion on '64bit'
 processing. What seems to be ignored so far is the simple 'bigint'
 value. Limiting 32 bit systems to only support 32 bit integers may be
 the easy solution, but bigint is an essential element of most database
 type sets these days, so should be supported transparently. If a primary
 key is provided as part of a database result set, then do we really want
 the situation where some installs fall over with an overflow of that key
 on 32 bit systems? Having to use a secondary level function exclusively
 simply because the core processing gets it wrong is another mistake?
 
 Certainly it's not going to be easy to handle, and may not even be
 practical? But even the discussion on 'type hinting' seems to ignore the
 range problem where a 64bit value may be required but the installation
 on4y supports 32bit integers. Currently the value simply works with the
 string version …

Yeah, hence why I’m also proposing the bigint RFC, which intdiv() would work 
nicely with.
--
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 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] intdiv()


On 15 Jul 2014, at 06:17, Stas Malyshev smalys...@sugarcrm.com wrote:

 Why not? bcmath is in core since forever and has no external
 requirements, gmp builds practically everywhere too. AFAIR all distros
 have it.

Partly practicality, partly principle. A barebones installation of PHP may not 
include gmp or bcmath. If my bigint RFC got in, it would have to include the 
former, but that is a possible future and not the present reality.

I should point out that while, yes, bcmath could be used here, it is not 
efficient to do it by string manipulation (this is a type *natively supported* 
by literally every semi-modern processor and an operation built into C!). Also, 
gmp does the wrong thing, as will give you a gmp number result, whereas what I 
want is an integer. To use gmp is just as hackish as doing a floating-point 
division and casting, as the values we pass in would be converted to big 
integers, divided, then the resulting big integer would need to be manually 
converted back to a long.

It would make far more sense to simply support this basic, widely-supported and 
somewhat common operation than to encourage programmers to use poor workarounds 
which do not even work when a basic PHP installation is used.

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


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)


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)


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)

On Tue, Jul 15, 2014 at 4:09 PM, Rowan Collins rowan.coll...@gmail.com
wrote:

 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.

 :)


sorry, not a native speaker.
so you are saying that nobody argues that $someGenericStatement is not
proper grammar?
in my case the $someGenericStatement was that input validation is a
must(aka mandatory).
but I think that at this point I've made myself clear, so let's go back to
the topic (or continue the offtopic in private).

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

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


Ferenc Kovacs wrote (on 15/07/2014):

sorry, not a native speaker.


No problem, I think the intention was clear enough, and certainly meant 
no criticism. :)


so you are saying that nobody argues that $someGenericStatement is 
not proper grammar?
in my case the $someGenericStatement was that input validation is a 
must(aka mandatory).


It's valid, but inverts your intended meaning, since argues that 
means, roughly, supports.


So you had $nobody-supports($someGenericStatement) but intended 
$nobody-supports(! $someGenericStatement) or 
$everybody-supports($someGenericStatement)





--
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 14/07/2014):

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?


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


I realise there is not consensus on whether scalar hints should 
represent validation, cast, or a mixture, but *if* we go down the route 
of validation, then we have to choose which values are valid and which 
are not.


My preference is to keep that strict: the example others have posted of 
some_func($foo  BIT_FLAG) seems no more like a real boolean to me 
than some_func(strlen($foo)) or any other expression which yields an 
integer.


In fact, I'd find the behaviour more obvious if it were written 
some_func((bool)$foo  BIT_FLAG) - it makes clear that some_func is not 
itself aware of the flag, that's just the caller's way of making the 
decision. That the type hint encouraged that would therefore seem like a 
Good Thing.


(I'd post that comment on the appropriate sub-thread where that example 
was raised, but don't have time to find it...)


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)


On 15 Jul 2014, at 15:28, Rowan Collins rowan.coll...@gmail.com wrote:

 Stas Malyshev wrote (on 14/07/2014):
 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?
 
 The answer - which is definitely a matter of opinion - is that allowing any 
 string reduces the usefulness of the type hint.
 
 I realise there is not consensus on whether scalar hints should represent 
 validation, cast, or a mixture, but *if* we go down the route of validation, 
 then we have to choose which values are valid and which are not.
 
 My preference is to keep that strict: the example others have posted of 
 some_func($foo  BIT_FLAG) seems no more like a real boolean to me than 
 some_func(strlen($foo)) or any other expression which yields an integer.
 
 In fact, I'd find the behaviour more obvious if it were written 
 some_func((bool)$foo  BIT_FLAG) - it makes clear that some_func is not 
 itself aware of the flag, that's just the caller's way of making the 
 decision. That the type hint encouraged that would therefore seem like a Good 
 Thing.
 
 (I'd post that comment on the appropriate sub-thread where that example was 
 raised, but don't have time to find it…)

Right. For the sake of consistency with the other scalar type hints, I’m 
current leaning to what I’ve made the RFC do, i.e. be completely strict for 
booleans. This is because we have string, float and int only allow losslessly 
convertible, equivalent values. Unfortunately, I’d argue there aren’t really 
such things for booleans except for true and false. Furthermore, forcing people 
to cast here isn’t such a bad thing; a cast to bool will always be somewhat 
lossy, and while explicitly casting to int or float might be dangerous, I can’t 
think of any place where it’s actually a bad idea to explicitly cast to bool.

--
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-15 Thread Philip Sturgeon

On Mon, Jul 14, 2014 at 11:16 PM, Park Framework
park.framew...@gmail.com wrote:
 Maybe we should make two different syntax?

 fun(int $num, array $list)   - for strict type compliance
 fun((int) $num, (array) $list)  - converted to type

 It will be very obvious, and without magic.


 2014-07-14 23:23 GMT+03:00 Chuck Reeves chuck.ree...@gmail.com:

 I am new to the list and internals so my question might be obvious to
 others: Why even cast the variable? When I look at a function and see:


 function myFunc(array $someData)
 {
 //some processing
 }

 I understand that myFunc requires an array passed in.  If I try to call
 myFunc like so:

 myFunc('foobar');

 I get a fatal error stating that I did not pass in an array.  If I try with
 stdClass:

 myFunc(new \stdClass());

 I will get the same error however If I cast the object before passing in
 like so:

 myFunc((array) new \stdClass());

 It works just fine.  The benefit of having the hint tells whom ever is
 going to consume the function that the parameter needs to be casted to the
 scalar type.

 If I have this:

 function addTwoValues(int $valueOne, int $valueTwo);

 It is clear that i need to make sure I'm using int's.  If I try to call
 that function with any other type, I would like to get the error instead of
 some kind of auto-magical cast into something that could product strange
 results.

 I think the benefit is in having the hint with excluding the cast of the
 value.  Let the user cast the value to what the function requires.  IMHO
 Allow the author of the function to dictate what is needed to execute.


 On Mon, Jul 14, 2014 at 3:59 PM, Andrea Faulds a...@ajf.me wrote:

 
  On 14 Jul 2014, at 20:53, Rowan Collins rowan.coll...@gmail.com wrote:
 
   The debate in this thread basically comes down to us each wanting our
  favourite from that list of features to have the privilege of dedicated
  syntax in function signatures.
 
  That’s why this RFC is supposed to be a best-compromise solution between
  strict and just casting. The hope is to appease both sides and provide
 the
  most workable solution, really. It’s also the style that I, myself, like
  best, because it’s strict enough to catch bugs (I like that), and it
 keeps
  PHP a type-shifting language (I like that too).
 
  --
  Andrea Faulds
  http://ajf.me/
 
 
 
 
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 



A massive +1 for this approach. I had the same thought the other day
after watching this thread aganoise between to cast, or not to cast.

Trying to make some types automatically cast and some just assert
(like some do already) is a road that leads to pain and suffering.

Trying to make them all just assert is not the PHP way.

Trying to make them all cast (thus changing the exist array assertion
into a cast action) would be bizarre and strange.

So what is left? Two syntaxes, so cast and assert can both be taken care of.


foo(int $num)   - for strict type compliance

This HAS to be an int and an array. Nothing else will fly.

bar((int) $num)  - converted to type

This has to be anything that could be turned into an int, which to be
fair is basically anything, and anything that can be turned into an
array.

foo(123); // OK
foo(123); // Not OK
foo(123a); // Really not OK

bar(123); // OK
bar(123); // Casts to 123
bar(123a); // Casts to 123
bar( 123a); // Casts to 123

Even if you guys would like to suggest that foo(123); should be ok
because $_GET variables, I would sill strongly urge people to consider
the type assertions dont cast approach, and add easy casting for
assert and cast functionality.

It's the most consistent and easy to explain approach, even if it does
lead to the occasional developer saying Oh, my unfiltered $_GET input
is a string instead of an int. How do I... ahh I just use foo((int)
$_GET['whatever']);

Not an issue in 2014 I believe.

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

 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.

Having one set of rules for explicit casts and one set of rules for
implicit casts (all of them) may work. Having more than one set of rules
for implicit cast  makes no sense to me at all and will only lead to
more confusion and frustrated users. Yes, I understand you want to serve
more use cases, but you will never serve them all, and IMO consistent
approach is much more important than serving 0.01% of cases where
converting 1 or object to boolean is really an error.
-- 
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)

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.

 In fact, I'd find the behaviour more obvious if it were written 
 some_func((bool)$foo  BIT_FLAG) - it makes clear that some_func is not 
 itself aware of the flag, that's just the caller's way of making the 
 decision. That the type hint encouraged that would therefore seem like a 
 Good Thing.

What you want is strict typing then. And if() working the same way -
after all, if function can be unaware of the flag, if() is definitely
unaware of it. So you'll always have to write if(($foo  BIT_FLAG) !=
0). Some would say it's an improvement. I am not among them. If you want
to enforce code style, we already have tools for that, but I don't think
this particular one should be in the language.

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


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

IMO, having consistent rules is much more, orders of magnitude more
important than serving any particular use case


We are adding a new feature to a language which is already inconsistent. 
We can only make it consistent with one part of the language by making 
it inconsistent with another.


If we take consistency as such a priority that we create a feature that 
is not actually useful, we will have wasted our effort, and made the 
language worse, not better. Saying who cares if its useful, as long as 
it matches some other part of the language is a very poor argument IMO.


That's an extreme, and I'm not saying anyone is saying precisely that, 
but I am getting rather weary of the back-and-forth over what is 
consistent, rather than thinking about what we want to achieve, and 
what is the best way to achieve that.



What you want is strict typing then.


No, I want to introduce the notion of a lossless cast, allowing things 
like (int)'123' to be valid. This distinction has been explained many times.



And if() working the same way -
after all, if function can be unaware of the flag, if() is definitely
unaware of it.


Not necessarily. An if() statement is clearly and unambiguously working 
with boolean values. Anyone looking at if( $foo  BIT_FLAG ) can know, 
based on basic knowledge of the language, that an implicit cast is 
taking place.


Someone looking at my_super_function( $foo  BIT_FLAG ) cannot know 
whether that parameter is being interpreted as a boolean or is actually 
being measured against that same BIT_FLAG (or some other integer 
operation) without consulting the source code (or, at least, trusting 
the documentation).



I am not among them. If you want
to enforce code style, we already have tools for that, but I don't think
this particular one should be in the language.


The logical conclusion from that is not to have type hints at all. So 
far, that is in fact the only consensus the PHP community has ever 
reached - not to have scalar type hints. (I don't mean that you 
necessarily hold that position, but it is the logical conclusion of that 
particular line of reasoning.)


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)


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

 Stas Malyshev wrote (on 15/07/2014):
 IMO, having consistent rules is much more, orders of magnitude more
 important than serving any particular use case
 
 We are adding a new feature to a language which is already inconsistent. We 
 can only make it consistent with one part of the language by making it 
 inconsistent with another.
 
 If we take consistency as such a priority that we create a feature that is 
 not actually useful, we will have wasted our effort, and made the language 
 worse, not better. Saying who cares if its useful, as long as it matches 
 some other part of the language is a very poor argument IMO.
 
 That's an extreme, and I'm not saying anyone is saying precisely that, but I 
 am getting rather weary of the back-and-forth over what is consistent, 
 rather than thinking about what we want to achieve, and what is the best way 
 to achieve that.

I’d argue it’s better to do the right thing here, which is easier, and then do 
the right thing in the other place later, which is harder, than it is to do the 
wrong thing now because the other place also does the wrong thing. Having saner 
implicit casting for scalar type hints will be easier than changing the 
behaviour of zend_parse_parameters.

 What you want is strict typing then.
 
 No, I want to introduce the notion of a lossless cast, allowing things like 
 (int)'123' to be valid. This distinction has been explained many times.

 And if() working the same way -
 after all, if function can be unaware of the flag, if() is definitely
 unaware of it.
 
 Not necessarily. An if() statement is clearly and unambiguously working with 
 boolean values. Anyone looking at if( $foo  BIT_FLAG ) can know, based on 
 basic knowledge of the language, that an implicit cast is taking place.
 
 Someone looking at my_super_function( $foo  BIT_FLAG ) cannot know whether 
 that parameter is being interpreted as a boolean or is actually being 
 measured against that same BIT_FLAG (or some other integer operation) without 
 consulting the source code (or, at least, trusting the documentation).
 
 I am not among them. If you want
 to enforce code style, we already have tools for that, but I don't think
 this particular one should be in the language.
 
 The logical conclusion from that is not to have type hints at all. So far, 
 that is in fact the only consensus the PHP community has ever reached - not 
 to have scalar type hints. (I don't mean that you necessarily hold that 
 position, but it is the logical conclusion of that particular line of 
 reasoning.)
 
 Regards,
 Rowan Collins
 -- 
 [IMSoP]
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 

I, myself, generally agree with all this, though I’m not sure quite whether 
Anthony does at the moment.
--
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)


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

Having more than one set of rules
for implicit cast  makes no sense to me at all and will only lead to
more confusion and frustrated users.


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 
as mentioned elsewhere, I'd be happy for them to exist outside of 
function signatures too as a new notion of strict cast.


That way, we remove the expectation that they will act the same as some 
other feature, and can simply evaluate their usefulness as a new, 
separate, feature.


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


Ford, Mike wrote (on 15/07/2014):

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


Ooh, skimming that, I see suggestions for prefixes and suffixes to 
represent types of cast (or hint).


That fits nicely with my thoughts on making strict cast a first-class 
citizen of the language, rather than isolating it to function 
signatures, e.g.:


$foo = 'abc'; $foo = (int)$foo; // OK, evaluates to int(0)
$foo = 'abc'; $foo = (int!)$foo; // ERROR
$foo = '42'; $foo = (int!)$foo; // OK, evaluates to int(42)

--
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 Jul 2014, at 18:39, Rowan Collins rowan.coll...@gmail.com wrote:

 Ooh, skimming that, I see suggestions for prefixes and suffixes to represent 
 types of cast (or hint).
 
 That fits nicely with my thoughts on making strict cast a first-class 
 citizen of the language, rather than isolating it to function signatures, 
 e.g.:
 
 $foo = 'abc'; $foo = (int)$foo; // OK, evaluates to int(0)
 $foo = 'abc'; $foo = (int!)$foo; // ERROR
 $foo = '42'; $foo = (int!)$foo; // OK, evaluates to int(42)

It’s a shame Nikita’s Exceptions in the Engine RFC failed, as being able to do 
this would be nice:

try {
$foo = (int!)$foo;
} catch (RecoverableError) {
$foo = 1;
}

Perhaps some sort of similar syntax? `(int!)$foo else 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)


Andrea Faulds wrote (on 15/07/2014):

It’s a shame Nikita’s Exceptions in the Engine RFC failed, as being able to do 
this would be nice:

try {
 $foo = (int!)$foo;
} catch (RecoverableError) {
 $foo = 1;
}

Perhaps some sort of similar syntax? `(int!)$foo else 0`?


I was thinking the same thing myself as I wrote it. My main disagreement 
with the EngineExceptions as they were proposed was that I think 
meaningful sub-classes are a must:


try {
$foo = (int!)$foo;
} catch (UnsafeCastException $e) {
$foo = 1;
}



My other thought was to have a syntax for is this cast safe?, e.g. 
(int?) but the more I play with it, the more ugly it feels:


if ( ! (int?)$foo ) {
  $foo = 1;
}


I'd still like to see some readable way of writing that, though. The 
only built-in function I know of which comes close is filter_var(), 
which feels like a bit of a sledgehammer:


if ( false === filter_var($foo, FILTER_VALIDATE_INT) ) {
 throw new UnsafeCastException;
}

Or, to implement a safe cast, and catch the error case:

if ( false === $foo = filter_var($foo, FILTER_VALIDATE_INT) ) {
 $foo = 1;
}

Yuck! :P

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

On Tue, Jul 15, 2014 at 8:24 PM, Rowan Collins rowan.coll...@gmail.com wrote:

 The logical conclusion from that is not to have type hints at all. So far,
 that is in fact the only consensus the PHP community has ever reached - not
 to have scalar type hints.

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.

PHP internals on the other hand, would rather argue to death over
which specific version of the two is the one and true way to rule them
all. We had that with the ArrayOf hints too, which turned into ArrayOf
vs Generics.

Heritage this, history that, consistent with X, inconsistent with Y,
don't forget the special case Z, use another language, that's been
proposed already ... That is why an Nth iteration of scalar type
hinting is being discussed, not because it's so damn hard to do it
right. Doing it right here means to understand that everybody wants
scalar type hinting for different use cases and to try to satisfy use
case A without excluding use case B as a possibility in the future.

Sorry about the rather aggressive remark, but somebody had to say it.

Cheers,
Andrey.

-- 
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 Jul 2014, at 19:59, Rowan Collins rowan.coll...@gmail.com wrote:

 Or, to implement a safe cast, and catch the error case:
 
 if ( false === $foo = filter_var($foo, FILTER_VALIDATE_INT) ) {
 $foo = 1;
 }
 
 Yuck! :P

The patch and RFC introduce a new set of “safe” conversion functions which we 
could use for these safe casts. In fact, it makes normal casts use them too 
now, they just ignore the errors.

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

Perhaps safe_int or something would be better. Anyhow, (int!) would error if 
the cast was unsafe, but as you'd checked ahead of time, it wouldn’t error here.

That, or perhaps something with an optional argument:

$bar = cast_int($foo, 1); // defaults to 1 if cast unsafe
$bar = cast_int($foo); // unsafe cast

But I don’t like that approach as it doesn’t match the nice (int!) syntax.

This just occurred to me:

$bar = (int?)$foo ? (int!)$foo : 1;

I’m not sure if that’s horrible or brilliant.

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

It’s also that I, myself, actually would prefer this proposal to either cast 
hinting or strict declarations… so that’s three ways to support if we’re going 
down that route.

Really, I think we should settle on a compromise, not on one way, the other, or 
both. This RFC is a compromise.

--
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-15 Thread Andrey Andreev

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

 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.

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), then a camp that wants X doesn't mean a camp that
doesn't want Y, so we end up with:

Camps wanting one + camps wanting another == a larger camp that
wants all of it

A compromise isn't excluded by this. It would just have to be a ok,
let's do X right now and we'll think about Y later compromise (point
being, don't exclude Y) instead of a let's have a mixed something
between the two that nobody really, really likes one.

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

On Tue, Jul 15, 2014 at 11:02 PM, Andrey Andreev n...@devilix.net wrote:
 On Tue, Jul 15, 2014 at 10:48 PM, Andrea Faulds a...@ajf.me wrote:

 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.

 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), then a camp that wants X doesn't mean a camp that
 doesn't want Y, so we end up with:

 Camps wanting one + camps wanting another == a larger camp that
 wants all of it

 A compromise isn't excluded by this. It would just have to be a ok,
 let's do X right now and we'll think about Y later compromise (point
 being, don't exclude Y) instead of a let's have a mixed something
 between the two that nobody really, really likes one.

To further clarify, it also doesn't mean a promise on Y, just don't
provocate people to bring it up again when it's not the current task.

My $0.02.

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

I’d prefer a middle path, a “third way” of sorts (hah, another thing stolen 
from political politics), rather than going in two opposing directions 
simultaneously.
--
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 PHP community that I know, wants to have _both_ type cast hinting
 and strict type declarations.

No, different members of the community want different options, because
it would serve their particular use cases. But that does not mean it
necessarily must be part of PHP - not all use cases must and can be
served by the language. Something will inevitably be left out.

 PHP internals on the other hand, would rather argue to death over

PHP internals would rather have consistent implementation that we can
build on and support for next 10 years than serve one particular use
case which may even not be there in 2 years or create a hodgepodge of
syntaxes just to ensure nobody is left out. Yes, that means sometimes we
argue a lot and sometimes we reject your favorite use case. Figuring
what is right for a tool used by a diverse community of millions is not
easy, and what could seem obviously right to you may seem as obviously
wrong to somebody else. Sometimes it is better to not implement
something than implement it wrong and be stuck with it for the next decade.
-- 
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)

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?

 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.
Especially as you won't even know which rules something as simple as
foo($bar) would invoke.

 That way, we remove the expectation that they will act the same as some 
 other feature, and can simply evaluate their usefulness as a new, 
 separate, feature.

It's not a new, separate feature. It can not be separate from what
already exists in the language. That's the whole point of it - not
concentrating on one use case but looking how it sits together with the
rest of the language.
-- 
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 15 Jul 2014, at 22:02, Stas Malyshev smalys...@sugarcrm.com wrote:

 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.
 Especially as you won't even know which rules something as simple as
 foo($bar) would invoke.

To be fair, we already have this. The type hint convention is 
E_RECOVERABLE_ERROR, the zend_parse_parameters convention is E_WARNING and 
return FAILURE (usually resulting in a bailout and hence NULL result in the 
function calling zpp).

I’d rather make type hints do the right thing here now and hopefully change zpp 
later, whether that’s realistically achievable or not. Unfortunately we already 
have two different error behaviours, and I expect resistance to changing type 
hints to do what zpp does (too soft touch!), or changing zpp to do what type 
hints do (too harsh!”).

Also, sure, the scalar type hint behaviour is inconsistent with zpp in some 
cases (booleans, 12.5, “12a”), but it’s inconsistent with most of it, and you 
can describe what they do with a single sentence (“Scalar type hints will raise 
E_RECOVERABLE_ERROR if information is lost when casting.”), since they’re far 
more straightforward and obvious than zpp’s rules are.

--
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 15 Jul 2014, at 22:08, Andrea Faulds a...@ajf.me wrote:

 Also, sure, the scalar type hint behaviour is inconsistent with zpp in some 
 cases (booleans, 12.5, “12a”), but it’s inconsistent with most of it, and you 
 can describe what they do with a single sentence (“Scalar type hints will 
 raise E_RECOVERABLE_ERROR if information is lost when casting.”), since 
 they’re far more straightforward and obvious than zpp’s rules are.

Er, I meant “but it’s *consistent* with most of 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] intdiv()

Hi Andrea,

On Tue, Jul 15, 2014 at 11:10 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 On Tue, Jul 15, 2014 at 9:14 AM, Andrea Faulds a...@ajf.me wrote:

 PHP currently lacks a way to do integer division. You can floor or int
 cast a floating-point division, but beyond 53-bits that produces the wrong
 result:

 $ sapi/cli/php -r 'var_dump((int)(PHP_INT_MAX / 3));'
 int(3074457345618258432)

 Furthermore, using a floating-point division isn’t really a proper way to
 do it; it’s a workaround for a lack of language support for a quite basic
 operation. This RFC proposes a function for integer division, intdiv(). It
 would work properly with 64-bit values:

 $ sapi/cli/php -r 'var_dump(intdiv(PHP_INT_MAX, 3));'
 int(3074457345618258602)


 We have GMP object from 5.6 and we can do

 [yohgaki@dev php-5.6]$ ./php-bin -r '$i = gmp_init('21342'); $a = $i / 3;
 var_dump($a);'
 object(GMP)#2 (1) {
   [num]=
   string(4) 7114
 }
 [yohgaki@dev php-5.6]$ ./php-bin -r '$i = gmp_init('21342'); $a = $i *
 ; var_dump($a);'
 object(GMP)#2 (1) {
   [num]=
   string(13) 2134199978658
 }

 IMHO, GMP is the choice when precise computation is needed as it could be
 any number.
 Native integer type is much faster for sure. Question is do we really need
 it?


If we are going to have integer arithmetics, it may be better to have full
set of operators/functions

https://bugs.php.net/bug.php?id=30701

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] [RFC] intdiv()


On 15 Jul 2014, at 23:12, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 If we are going to have integer arithmetics, it may be better to have full 
 set of operators/functions
 
 https://bugs.php.net/bug.php?id=30701

I’d rather not go to that length, but if someone wants to do that, they may.

Bigints might help here… although they might also cause more problems in places.

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





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

[PHP-DEV] crypt() BC issue

Hi all,

crypt() has BC issue with older systems.

https://bugs.php.net/bug.php?id=62372edit=1

The reason rounds became 1000 from 10 is hardcoded lower limit for newer
PHPs.
Generally speaking, developer should never use less than 1000 rounds and
better to have
at least few thousands rounds or more, tens of thousands or more is
recommended.

I would like to make this bug report 'wont fix', since migration is
possible.

 - Developer may use larger rounds and store updated hash when
   user is authenticated with old PHP.
 - Developer may ask users to reset password if password hash has
   to fewer rounds than 1000 (i.e. outdated hash) with new PHP.

Any comments?

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] crypt() BC issue


On 16 Jul 2014, at 01:46, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 - Developer may use larger rounds and store updated hash when
   user is authenticated with old PHP.
 - Developer may ask users to reset password if password hash has
   to fewer rounds than 1000 (i.e. outdated hash) with new PHP.

Wait, doesn’t that mean you’re unable to verify passwords now?
--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] crypt() BC issue


On 16 Jul 2014, at 02:45, Yasuo Ohgaki yohg...@ohgaki.net wrote:

 This change was done while ago, so it would not worth the effort to relax
 the requirement now. IMHO.
 
 We may add optional flag to relax the limitation, though.
 I don't mind modifying crypt() or adding migration INI setting.

Yeah, that’s my thoughts as well. We changed it for a reason, but to avoid 
breaking things, perhaps a migratory INI setting (which we’d eventually remove) 
is for the best.
--
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] intdiv()

2014-07-15 Thread Bishop Bettini

Hi Andrea,

TL;DR -- I agree with the principal but want implemented as the infix
operator %% with a test for PHP_INT_MIN %% -1 === false (and a E_WARNING).

As a user, I could implement intdiv and get the same functionality as
proposed:
function intdiv($n, $d) { return (int)($n / $d); }

Heck, I could even simplify further:
function intdivmod($n, $d, $m = 1) {
return (int)($n / $d) % $m;
}

Though an internal implementation would be faster and would bypass the
float truncation issue (which IMO is a separate issue and neither a pro nor
con for this RFC),  I feel like we need to confer additional benefit if we
implement this in core.

Specifically, I'd want this implemented infix.  Let's call it // for now.
I'd like to be able to:

$x = 247 // 5;
$x //= 5;

The functional notation doesn't afford assign equals.  It collides with
user functions.  It complicates expressions.  (I also don't like pow()
functionally and wish PHP had an operator like ** for powers.)  So, why not
implement this as an actual operator?

As far as an operator, that's trickier. // and \ would be most like
existing languages, but those are problematic as already stated.  We could
overload /, relying on the left and right operands to be int to induce
integer division... but I'm pretty sure that would be more hassle than it's
worth.  So the best I can think of is %%.  That seems ok to me, since there
is some family resemblance between modulus and integer division.

Finally, I think a test on the other side of the spectrum is needed:
PHP_INT_MIN %% -1.  Mathematically that should be PHP_INT_MAX+1, I believe,
so a warning and false seems appropriate.

Regards,
bishop
On Jul 15, 2014 8:11 AM, Andrea Faulds a...@ajf.me wrote:


 On 15 Jul 2014, at 03:31, Bishop Bettini bis...@php.net wrote:
  I need some education.  Can you elaborate on the specific situations
 where integer division would be used without other functions from bcmath or
 gmp?
 
  I see in the RFC you mention seconds to hh:mm and index to rows/cols,
 but can you give some actual before and after samples?  Like this is
 how it would be done today without intdiv, and here's how it would be done
 after?

 Sure. Say I have a number of seconds which I wish to split into years,
 days, hours, minutes and seconds, for example:

 $s = 100;
 $seconds = $s % 60;
 $minutes = intdiv($s, 60) % 60;
 $hours = intdiv($s, 3600) % 24;
 $days = intdiv($s, 3600 * 24) % 365;
 $years = intdiv($s, 3600 * 24 * 365);

 Currently, you’d have to cheat and use floating-point division:

 $x = 100;
 $seconds = $s % 60;
 $minutes = (int)($s / 60) % 60;
 $hours = (int)($s / 3600) % 24;
 $days = (int)($s / (3600 * 24)) % 365;
 $years = (int)($s / (3600 * 24 * 365));

 The second one is a bit of a hack, really, but it would probably work most
 of the time since realistically nobody is using 53-bit time values at the
 moment (though people are using 32-bit values, so that 64-bit RFC can’t
 come soon enough given Y2K38).

 However, intdiv() is perhaps not the best way to implement it or the best
 syntax.

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

Re: [PHP-DEV] crypt() BC issue

Hi Andrea,

On Wed, Jul 16, 2014 at 10:47 AM, Andrea Faulds a...@ajf.me wrote:

  This change was done while ago, so it would not worth the effort to relax
  the requirement now. IMHO.
 
  We may add optional flag to relax the limitation, though.
  I don't mind modifying crypt() or adding migration INI setting.

 Yeah, that’s my thoughts as well. We changed it for a reason, but to avoid
 breaking things, perhaps a migratory INI setting (which we’d eventually
 remove) is for the best.


OK. I'll write a new RFC to add migration INI for this unless
there aren't any more comments.

 - Add bool crypt_migration INI that is default to OFF for PHP 5.4 and up.
 - master will not have this INI.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] [RFC] intdiv()


On 16 Jul 2014, at 02:51, Bishop Bettini bis...@php.net wrote:

 Hi Andrea,
 
 TL;DR -- I agree with the principal but want implemented as the infix
 operator %% with a test for PHP_INT_MIN %% -1 === false (and a E_WARNING).

%% is perhaps the only good non-keyword syntax choice. I like that.

 As a user, I could implement intdiv and get the same functionality as
 proposed:
function intdiv($n, $d) { return (int)($n / $d); }

You could, yes, but it wouldn’t return the correct result beyond 53-bit 
integers, and I’m not sure it would handle $x/-1 particularly well.

 
 Heck, I could even simplify further:
function intdivmod($n, $d, $m = 1) {
return (int)($n / $d) % $m;
}
 
 Though an internal implementation would be faster and would bypass the
 float truncation issue (which IMO is a separate issue and neither a pro nor
 con for this RFC),  I feel like we need to confer additional benefit if we
 implement this in core.
 
 Specifically, I'd want this implemented infix.  Let's call it // for now.
 I'd like to be able to:
 
 $x = 247 // 5;
 $x //= 5;
 
 The functional notation doesn't afford assign equals.  It collides with
 user functions.  It complicates expressions.  (I also don't like pow()
 functionally and wish PHP had an operator like ** for powers.)  So, why not
 implement this as an actual operator?

PHP *does* have an operator “like **” for powers… the ** operator. Did you 
somehow miss that RFC passing? :)

 
 As far as an operator, that's trickier. // and \ would be most like
 existing languages, but those are problematic as already stated.  We could
 overload /, relying on the left and right operands to be int to induce
 integer division... but I'm pretty sure that would be more hassle than it's
 worth.  So the best I can think of is %%.  That seems ok to me, since there
 is some family resemblance between modulus and integer division.

Right. This is just returning the other part of an integer division, the actual 
result itself, not the remainder.

 Finally, I think a test on the other side of the spectrum is needed:
 PHP_INT_MIN %% -1.  Mathematically that should be PHP_INT_MAX+1, I believe,
 so a warning and false seems appropriate.

The patch currently returns zero because I don’t want to yield a float like / 
does, but E_WARNING and FALSE sounds good, we do that for integer division 
anyway.


Do others on internals think that %% is a good syntax choice? Does anyone have 
an objection to it? It wouldn’t conflict with anything, it uses punctuation, 
and it makes sense.

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





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

[PHP-DEV] Use of php_mt_rand() rather than php_rand()