Re: [PHP-DEV] An BC issue in unserialize
Hi! in such case, the serialized data could be shared by 5.5 and 5.6... This is true, but what you presented is not serialized data. Serialized data will be fine. But the code you shown instead tries to use serializer as a roundabout way of instantiating objects. This is not the right thing to do, this was never the purpose of the serializer and was never guaranteed to work. -- 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] intdiv()
On 17 Jul 2014, at 04:23, Sara Golemon poll...@php.net wrote: Do we need a new operator for that? It feels un-php to me, and the kind of problem bigint objects should be meant to solve. On the other hand, having $a/$b != $a/$b (Off by more than 100 in this instance). But back on the first hand, that's consistent with other operations on large floats anyway. PHP_INT_MAX + 1 != One more than PHP_INT_MAX, Actually, my bigints RFC would retain the existing / behaviour (float result if non-zero remainder), so to avoid an unnecessary divisibility check or to deliberately ignore the remainder you’d need some sort of integer division operator there. On the other hand, that RFC would also see ext/gmp always available, I suppose. Of course this isn’t what ext/gmp does *now*, where it makes / be integer division (yuck). I think the / operator’s behaviour makes complete sense and Python 3 actually does exactly the same thing as PHP here, because what / does is the most intuitive thing. I suppose a function alone might do, but it feels a bit lacking to me not to have an operator for this. I’d also argue it’s not really un-PHP to add this, we already have the mod (%) operator and the bitwise operators also operate only on integers. Furthermore division ignoring the remainder is actually a fairly common use case (time for example), so I think there should be some way to do that when you need it. I wonder if the intent there might be clearer, too, than using floor() or (int). -- 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 Thu, Jul 17, 2014 at 10:25 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Tjerk, On Thu, Jul 17, 2014 at 11:09 AM, Tjerk Meesters tjerk.meest...@gmail.com wrote: Why should `password_verify()` work on a hash that wasn't generated with `password_hash()`? The fact that it uses `crypt()` internally should not leak outside of its API, imho. password_*() is designed as crypt() wrapper and this fact is documented since it was released. Obsolete password hash is easy to verify with password_needs_rehash(). Developers can check password database easily with password_needs_rehash(). The documentation states that the `hash` argument to both `password_needs_rehash()` and `password_verify()` is: hash - A hash created by password_hash(). Passing a value from your own crypt() implementation may work, but that shouldn't be relied upon. I certainly wouldn't classify it as a problem that should be fixed in the password api. i.e. They don't have to parse password hash to detect obsolete hash. Therefore, using password_*() for crypt() generated passwords makes sense. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- -- Tjerk
Re: [PHP-DEV] [RFC] intdiv()
On 17 Jul 2014, at 01:11, Bishop Bettini bis...@php.net wrote: As another contender, how about: $x = 242 %/ 7; $x %/= 13; The % reflects the relationship to modulus, while the / reflects the division effect. I think %/ looks worse, but I think it seems more apropos. I also quite like this one, and I’d prefer %/ to /%. What are internals's thoughts on this? Do you like %/ but not %%? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] An BC issue in unserialize
-Original Message- From: Stas Malyshev [mailto:smalys...@sugarcrm.com] Sent: Thursday, July 17, 2014 9:08 AM To: Laruence; Remi Collet Cc: PHP Internals Subject: Re: [PHP-DEV] An BC issue in unserialize Hi! in such case, the serialized data could be shared by 5.5 and 5.6... This is true, but what you presented is not serialized data. Serialized data will be fine. But the code you shown instead tries to use serializer as a roundabout way of instantiating objects. This is not the right thing to do, this was never the purpose of the serializer and was never guaranteed to work. My key concern is that I've now bumped into two applications - both OroCRM and also Taskada - that work fine with 5.5 but stop working with 5.6 because of that issue. Both are Symfony apps so it might be something that can be solved centrally in Symfony, but it may also be just coincidence. Either way, it's an indication that this would make upgrading to 5.6 harder than it needs to be, and a key tenet of our yearly release cycle was guaranteed pain-free upgrades. IMHO this isn't something we should change in a 2nd digit release, but on a major version, even if it wasn't documented. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] intdiv()
-Original Message- From: Andrea Faulds [mailto:a...@ajf.me] Sent: Wednesday, July 16, 2014 6:15 PM To: bis...@php.net Cc: PHP internals Subject: Re: [PHP-DEV] [RFC] intdiv() The RFC has been updated to v0.2. It now proposes a %% operator for integer division (with corresponding %%= assignment operator). However, it returns 0 for the PHP_INT_MIN overflow case like %, rather than FALSE and an E_WARNING. Guys, From debating whether it's worth it to add a new function for an not-so-commonly-used-operation-to-say-the-least, we're now seriously considering adding a new language level operator? Really? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] intdiv()
-Original Message- From: Kris Craig [mailto:kris.cr...@gmail.com] Sent: Thursday, July 17, 2014 6:02 AM To: Andrea Faulds Cc: Stas Malyshev; PHP internals Subject: Re: [PHP-DEV] [RFC] intdiv() On Tue, Jul 15, 2014 at 5:13 AM, Andrea Faulds a...@ajf.me wrote: Perhaps the RFC could have two options for approval; one with %% and the other with either %/ or /%. Thoughts? Yes, horrible ones :) I can't believe we're seriously considering adding an operator for something so uncommon. I'm actually in favor of adding APIs, but absolutely not an obscure operator. We're not Perl. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An BC issue in unserialize
Hi! IMHO this isn't something we should change in a 2nd digit release, but on a major version, even if it wasn't documented. We don't have much option here. Keeping it leads to a remote triggerable segfaults. We've discussed this here just recently. This is a hack that does not work properly with internal classes, and should not work too - the whole reason C: was created is because O: can not work with such classes. -- 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] intdiv()
On 17 Jul 2014, at 07:29, Zeev Suraski z...@zend.com wrote: From debating whether it's worth it to add a new function for an not-so-commonly-used-operation-to-say-the-least, we're now seriously considering adding a new language level operator? Really? Is it *really* not that common? I can think of several use-cases off the top of my head: * Time (actually pretty common in web apps, though we have a DateTime class) * Splitting into rows and columns * Pagination * Currency (you can’t, for example, represent the full number of BTC in circulation in BTC's base unit without using an integer of beyond 53-bits, and it’s common practise to use *fixed-point* arithmetic here) * Nearest-neighbour scaling * Most likely other ones (these are just what I thought of immediately) Also, while ** is great for some applications, it’s not going to be used much by others. Is the same not true of an integer division operator? On 17 Jul 2014, at 07:31, Zeev Suraski z...@zend.com wrote: I can't believe we're seriously considering adding an operator for something so uncommon. I'm actually in favor of adding APIs, but absolutely not an obscure operator. We're not Perl. Nor are we Python, but it is worth looking at just how many other languages support this considering it’s actually very useful in some situations. I can think of C, C++, C#, Java, Objective-C, Visual Basic, Pascal, Python and Ruby to name a few popular ones. If you say that some of these implement it just because C does, I’m not sure that’s fair, as there are plenty of bad ideas in C which these don’t implement. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Use of php_mt_rand() rather than php_rand()
On Thu, Jul 17, 2014 at 1:02 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: RFC for this is created. https://wiki.php.net/rfc/use-php_mt_rand New rand() function name is TBD. I cannot think of good name, but I like rand_system(). rand() may stay as it is now also. I have mixed feelings about that. What did change since our last discussions? What are the benefits to do it now? Also I really do no think it is worse the effort and the addition to do it in 5.x. Yes, there are still apps out there relying on rand only for areas where it should not be used, but how is it our problem? I mean: the documentation is clear, have been updated and clarified many times. I'd rather focus on doing one set of APIs for RNG for php6 and leave that untouch for now. 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] intdiv()
Hi Andrea, On Thu, Jul 17, 2014 at 8:44 AM, Andrea Faulds a...@ajf.me wrote: On 17 Jul 2014, at 07:29, Zeev Suraski z...@zend.com wrote: From debating whether it's worth it to add a new function for an not-so-commonly-used-operation-to-say-the-least, we're now seriously considering adding a new language level operator? Really? Is it *really* not that common? I can think of several use-cases off the top of my head: * Time (actually pretty common in web apps, though we have a DateTime class) * Splitting into rows and columns * Pagination * Currency (you can’t, for example, represent the full number of BTC in circulation in BTC's base unit without using an integer of beyond 53-bits, and it’s common practise to use *fixed-point* arithmetic here) * Nearest-neighbour scaling * Most likely other ones (these are just what I thought of immediately) Also, while ** is great for some applications, it’s not going to be used much by others. Is the same not true of an integer division operator? The rare cases where I had to do that, I relied on bcmath or gmp. Yes, I needed some extra ops to actually achieve what this RFC proposes but it is good enough. The new ops overloading for extension simplifies that a lot as well. I am sorry but I'd to say -1 on this addition, not worse a new operator or function for this. 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] intdiv()
On 17 Jul 2014, at 07:56, Pierre Joye pierre@gmail.com wrote: The rare cases where I had to do that, I relied on bcmath or gmp. Yes, I needed some extra ops to actually achieve what this RFC proposes but it is good enough. The new ops overloading for extension simplifies that a lot as well. I am sorry but I'd to say -1 on this addition, not worse a new operator or function for this. How on earth is adding a nearly-universal function everywhere else to PHP’s math library so controversial, let alone as an operator? Yes, you *can* do it with bcmath or gmp, but one should question why you *should*, given that it’s a horrible workaround. -- 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()
-Original Message- From: Andrea Faulds [mailto:a...@ajf.me] Sent: Thursday, July 17, 2014 9:44 AM To: Zeev Suraski Cc: bis...@php.net; PHP internals Subject: Re: [PHP-DEV] [RFC] intdiv() On 17 Jul 2014, at 07:29, Zeev Suraski z...@zend.com wrote: From debating whether it's worth it to add a new function for an not-so-commonly-used-operation-to-say-the-least, we're now seriously considering adding a new language level operator? Really? Is it *really* not that common? I can think of several use-cases off the top of my head: * Time (actually pretty common in web apps, though we have a DateTime class) * Splitting into rows and columns * Pagination * Currency (you can't, for example, represent the full number of BTC in circulation in BTC's base unit without using an integer of beyond 53-bits, and it's common practise to use *fixed-point* arithmetic here) * Nearest-neighbour scaling * Most likely other ones (these are just what I thought of immediately) I think it is, given I believe it's the first time people are asking for this after PHP's been out for almost two decades... As the RFC itself suggests, you can use the current division for most use cases, including the ones mentioned above - they'd work in the vast majority of cases. I think the RFC should mention that it's already possible to do it using bcmath or gmp; That said, I tend to agree that we should have something like that in ext/standard, so I'm actually in favor of doing it - just not as an operator. Also, while ** is great for some applications, it's not going to be used much by others. Is the same not true of an integer division operator? To be honest, that operator was simply copied verbatim from Perl, back in the day when Perl ruled the Web world and minimizing the learning curve for Perl developers was an important goal. Not sure if we'd add it to the language had we not 'plagiarized' it from Perl... Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
On 17 Jul 2014, at 08:02, Zeev Suraski z...@zend.com wrote: I think it is, given I believe it's the first time people are asking for this after PHP's been out for almost two decades... As the RFC itself suggests, you can use the current division for most use cases, including the ones mentioned above - they'd work in the vast majority of cases. Yes, but as previously mentioned, beyond 2^52 it breaks down. What’s more worrying is the code out there written by people obviously unaware of this, but I shouldn’t use MtGox’s incompetence as a reason to fix PHP ;) I think the RFC should mention that it's already possible to do it using bcmath or gmp; It’s not possible to do with bcmath or gmp within the brief of “find the quotient of the division of two longs without requiring an extension”. Neither bcmath nor gmp is core PHP, and neither operate on longs, though you can be silly and convert a long to a string, in bcmath’s case, or a gmp object, in gmp’s case, then do the operation, then convert back, checking for the two failure cases, of course. That said, I tend to agree that we should have something like that in ext/standard, so I'm actually in favor of doing it - just not as an operator. Well, that’s better than nothing I suppose, but I’d still rather use something infix. To be honest, that operator was simply copied verbatim from Perl, back in the day when Perl ruled the Web world and minimizing the learning curve for Perl developers was an important goal. Not sure if we'd add it to the language had we not 'plagiarized' it from Perl… Huh? ** was added by an RFC this year. Actually, since 5.6 isn’t out yet, it’s technically not part of PHP yet... -- 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! * Time (actually pretty common in web apps, though we have a DateTime class) Admittedly, we're getting closer to the dreaded year 2038, but what does it actually mean to divide current Unix timestamp by 3 and why one would ever want to do this? We also have classes for real datetime calculations. * Splitting into rows and columns * Pagination Here you are onto something, but how often you paginate data sets of MAXINT size and need exact number of pages? * Currency (you can’t, for example, represent the full number of BTC in circulation in BTC's base unit without using an integer of beyond 53-bits, and it’s common practise to use *fixed-point* arithmetic here) If you're using ints for currency, you're probably doing it wrong. If you're dividing currency using integer division, I don't even know what you are trying to do, except reenacting Office Space :) * Nearest-neighbour scaling You mean image processing? If 53 bit precision is not enough there, I'm not even sure PHP should be doing that. IMHO this is not enough for a new operator... Especially if this means we have to tolerate something like %/. -- 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] intdiv()
-Original Message- From: Andrea Faulds [mailto:a...@ajf.me] Sent: Thursday, July 17, 2014 10:09 AM To: Zeev Suraski Cc: bis...@php.net; PHP internals Subject: Re: [PHP-DEV] [RFC] intdiv() On 17 Jul 2014, at 08:02, Zeev Suraski z...@zend.com wrote: I think it is, given I believe it's the first time people are asking for this after PHP's been out for almost two decades... As the RFC itself suggests, you can use the current division for most use cases, including the ones mentioned above - they'd work in the vast majority of cases. Yes, but as previously mentioned, beyond 2^52 it breaks down. What's more worrying is the code out there written by people obviously unaware of this, but I shouldn't use MtGox's incompetence as a reason to fix PHP ;) I think the RFC should mention that it's already possible to do it using bcmath or gmp; It's not possible to do with bcmath or gmp within the brief of find the quotient of the division of two longs without requiring an extension. Neither bcmath nor gmp is core PHP, and neither operate on longs, though you can be silly and convert a long to a string, in bcmath's case, or a gmp object, in gmp's case, then do the operation, then convert back, checking for the two failure cases, of course. It's still possible to do. When people vote on a new feature the full context should be clear. Again, I'm supporting your RFC (in its original form at least) - but we should provide as much information as possible in the RFC to give voters the full context. That said, I tend to agree that we should have something like that in ext/standard, so I'm actually in favor of doing it - just not as an operator. Well, that's better than nothing I suppose, but I'd still rather use something infix. PHP's not Perl. Let's keep it that way please... To be honest, that operator was simply copied verbatim from Perl, back in the day when Perl ruled the Web world and minimizing the learning curve for Perl developers was an important goal. Not sure if we'd add it to the language had we not 'plagiarized' it from Perl. Huh? ** was added by an RFC this year. Actually, since 5.6 isn't out yet, it's technically not part of PHP yet... OK, this RFC passed well under my radar. I thought we had it forever, and indeed I never found a reason to use it :) I'd probably vote against it if I was aware of it, but given it's common in other languages, I wouldn't have strongly opposed it. I don't think it makes sense to add a specialized integer division operator when we do have a different division operator, and I don't think other dynamic languages have such an operator - so unlike **, there's no established precedent... Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
On 17/07/14 04:23, Sara Golemon wrote: Wow. I just finally understood what your RFC was going for. I thought you were trying to cover the case where ($a%$b)==0, but you're not, you're trying to do truncated integer division regardless of remainder. I also missed the fact that div_function does the right thing already as well. My bad for emailing from the bus. Okay, that's another animal entirely. Displaying time intervals is probably one of the best examples of what is needed, but the 'different animal' that I'd like to be able to handle transparently is a 'bigint' based index key. One that provides clean 64bit results what ever the hardware base, 'intdiv' and 'mod' giving 'bigint' results which are the two elements of a 'moddiv' result. I am perhaps a little spoilt since I can do all of this already in the Firebird database layer ... and since it's the data from there I'm working with in private code I do not have a problem, but Firebird's 'arithmetic' is not consistent with other engines or PHP. One useful feature on Firebird is (26 / 3) gives 8 while (28 / 3.00) gives 8.66 - one can tailor the accuracy of the result simply be loading the input. This can be irritating at first, but surprisingly useful at times! Time handling in Firebird introduces another variation which I duplicate to other engines when needed! A timestamp is essentially 2 32 bit integers ... one for days and the other 'part of day' - time as a fraction of day. This can be used as a 'bigint' value for array indexes - calendar elements is a good example - or can be split essentially like the 'moddiv' result to give two integer keys but 32bit ones. Conversion of this to a 64bit 'unit seconds based' time is a point where one does not want results wrapped to PHP float values ;) The point I'm trying to reiterate and expand on is that the integer base size is as important here as integer division, and one size does not fit all. -- 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] intdiv()
On 17 Jul 2014, at 08:19, Zeev Suraski z...@zend.com wrote: PHP's not Perl. Let's keep it that way please… I don't think it makes sense to add a specialized integer division operator when we do have a different division operator, and I don't think other dynamic languages have such an operator - so unlike **, there's no established precedent… True, but PHP clearly drew inspiration from Perl, and C, which also has integer division. Many of these languages don’t have an integer division operator simply because they don’t need one. In most C-like languages and plenty of non C-like, an integer divided by an integer is always an integer, and you only get a float result if one or more operands are a float. However, in languages like PHP, Python, Visual Basic and Pascal, the division operator is unusually (though I’d say more intuitively) defined as sometimes giving a float for integer operands. In the case of PHP and Python, this is only when the the second operand isn’t a factor, while in the case of VB and Pascal, / always results in a float. It is in these languages that we find the much rarer integer division operator (Python has //, Visual Basic has \, Pascal has div) because you can’t do it the “normal” way. In this respect, it’s rather unusual that PHP lacks an integer division operator, or even some built-in way to do integer division at all, given that all its peers do support it. There are also languages which don’t have integers, like JavaScript. In JS there’s no need for such an operator as, since it doesn’t have integers anyway, Math.floor(x / y) isn’t going to lose any accuracy. Makes me wonder why we don’t have one after all these years. I assume either the division operator hasn’t always done what id does now (I’m not a historian, so I couldn’t tell you that), or that people have tended to just go for floor(x / y). After all, that works perfectly on 32-bit platforms. ;) -- 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 17/07/14 08:02, Zeev Suraski wrote: I think it is, given I believe it's the first time people are asking for this after PHP's been out for almost two decades... As the RFC itself suggests, you can use the current division for most use cases, including the ones mentioned above - they'd work in the vast majority of cases. What has happened in the intervening 20 years is that we have moved from having 16 bit computer systems on the desk to 64bit computers on our wrists? Coming up with some new operator is a pointless distraction. The ones we have are enough, they just need to be brought into the 21st century consistently, yet still work on the historic machines some people stile prefer ... just as PHP needs to handle unicode transparently it also needs to handle 64bit integers ... -- 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] intdiv()
On 17 Jul 2014, at 08:17, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! * Time (actually pretty common in web apps, though we have a DateTime class) Admittedly, we're getting closer to the dreaded year 2038, but what does it actually mean to divide current Unix timestamp by 3 and why one would ever want to do this? We also have classes for real datetime calculations. To divide by three is probably a bad example, but it’s fair to point out that anything with UNIX timestamps would work fine with just floats as we don’t need 53 bits yet. Here you are onto something, but how often you paginate data sets of MAXINT size and need exact number of pages? Rarely, I suspect, but it would still be nice to have a proper way of doing the division If you're using ints for currency, you're probably doing it wrong. If you're dividing currency using integer division, I don't even know what you are trying to do, except reenacting Office Space :) A lot of people use ints as a poor man’s fixnum, and sometimes that’s actually the right way to implement them. IIRC, Bitcoin is implemented using 64-bit integers internally. You mean image processing? If 53 bit precision is not enough there, I'm not even sure PHP should be doing that. True, but again, you should still ask why PHP doesn’t support integer division in the first place. IMHO this is not enough for a new operator... Especially if this means we have to tolerate something like %/. %/ and %% are hardly the nicest operators, no. Myself I like %% as % being one part and %% being the other part of an integer division makes sense to me, but I can see why others might not like 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] An BC issue in unserialize
On Thu, Jul 17, 2014 at 8:43 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! IMHO this isn't something we should change in a 2nd digit release, but on a major version, even if it wasn't documented. We don't have much option here. Keeping it leads to a remote triggerable segfaults. We've discussed this here just recently. This is a hack that does not work properly with internal classes, and should not work too - the whole reason C: was created is because O: can not work with such classes. As discussed in previous threads about this failure, we (doctrine) can move away from the `unserialize()` hack if `ReflectionClass#newInstanceWithoutConstructor()` provides support for internal classes. It doesn't need to cover ALL internal classes, just the most commonly extended ones. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] An BC issue in unserialize
Hi! As discussed in previous threads about this failure, we (doctrine) can move away from the `unserialize()` hack if `ReflectionClass#newInstanceWithoutConstructor()` provides support for internal classes. Could you explain why it is needed to instantiate internal classes without calling the ctor? I'd like to understand the use case more. It doesn't need to cover ALL internal classes, just the most commonly extended ones. The problem is we do not know which of these classes may fail if instantiated without initializing. With PHP classes, it's easy since the engine takes care of the basic plumbing. With C classes, if you don't call the function, you get nulls or worse, garbage, in places where values are expected. -- 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] An BC issue in unserialize
On Thu, Jul 17, 2014 at 9:58 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! As discussed in previous threads about this failure, we (doctrine) can move away from the `unserialize()` hack if `ReflectionClass#newInstanceWithoutConstructor()` provides support for internal classes. Could you explain why it is needed to instantiate internal classes without calling the ctor? I'd like to understand the use case more. I honestly don't have a use-case for it myself, and I also strongly disagree with extending internal PHP classes due to their fragility. What I know is that many Doctrine users extend `ArrayObject` in entities, which is what caused us to apply a hotfix only for 5.4.29 and 5.5.13, and NOT 5.6.0. It doesn't need to cover ALL internal classes, just the most commonly extended ones. The problem is we do not know which of these classes may fail if instantiated without initializing. With PHP classes, it's easy since the engine takes care of the basic plumbing. With C classes, if you don't call the function, you get nulls or worse, garbage, in places where values are expected. Yes, that indeed. What I am suggesting is to provide a small map of internal PHP classes that are supported by `ReflectionClass#newInstanceWithoutConstructor()`, so that their internal data can be initialized even if the userland constructor is not invoked. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] [RFC] intdiv()
On Thu, Jul 17, 2014 at 2:25 AM, Sara Golemon poll...@php.net wrote:
On Wed, Jul 16, 2014 at 8:15 AM, Andrea Faulds a...@ajf.me wrote:
Nikita Popov doesn’t seem to be a fan of the %% syntax, so it may be
subject to change, though I think it’s the best I’ve heard so far. ;)
Nor am I. Here's a thought though: How about just making / return int
when there's no remainder.
Looking at this code, you might think it's inefficent:
double dres = a / b;
long lres = a / b;
if (a % b) {
return dres;
} else {
return lres;
}
But in fact at -O1, gcc will optimize this (probably clang and others
as well) to a single idivq instruction and only do the cvtsi2sdq in
the dres case.
My point being, we can just make division with an integral result
return a result of integer division without altering the syntax or
adding a perf hit.
This is already what is currently happening, see
http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_operators.c#1067.
Andreas proposal is only useful in the case that the numbers don't divide
exactly and you need round-down/truncation behavior and your numbers are in
a range where the indirection through double arithmetic results in
precision loss.
Nikita
Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
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
[PHP-DEV] Fixing bug #66827
Hi all, https://github.com/php/php-src/pull/725 This is the fix for https://bugs.php.net/bug.php?id=66827 This kind of malformed data is an attack most likely, but raising error is not an option. Quick grep show no module nor core log error only. i.e. There is no error logging only code. All of them raises E_NOTICE/E_WARNING/etc. I would like to record a log that could be an attack. Since there is no code like this, I ask your opinions. The patch tries to remove offensive cookie, but it's far from perfect. In fact, removing all of offensive cookie in session module is impossible. We may let E_NOTICE raise and try the best it can. If it could remove offensive cookie, error is recorded and user may use their app from next request. Any comments? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] crypt() BC issue
Hi Tjerk, On Thu, Jul 17, 2014 at 3:16 PM, Tjerk Meesters tjerk.meest...@gmail.com wrote: On Thu, Jul 17, 2014 at 10:25 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Tjerk, On Thu, Jul 17, 2014 at 11:09 AM, Tjerk Meesters tjerk.meest...@gmail.com wrote: Why should `password_verify()` work on a hash that wasn't generated with `password_hash()`? The fact that it uses `crypt()` internally should not leak outside of its API, imho. password_*() is designed as crypt() wrapper and this fact is documented since it was released. Obsolete password hash is easy to verify with password_needs_rehash(). Developers can check password database easily with password_needs_rehash(). The documentation states that the `hash` argument to both `password_needs_rehash()` and `password_verify()` is: hash - A hash created by password_hash(). Passing a value from your own crypt() implementation may work, but that shouldn't be relied upon. I certainly wouldn't classify it as a problem that should be fixed in the password api It's easier to change crypt() behavior, since password_*() is crypt() wrapper. Are we going to relax the crypt() restriction permanently? It's ok for me. Users are better to use password_*() anyway. We must remove 72 bytes restriction in password_*() ASAP, though. i.e. blowfish truncates password longer than 72 bytes. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Re: Use of php_mt_rand() rather than php_rand()
Hi Pierre, On Thu, Jul 17, 2014 at 3:52 PM, Pierre Joye pierre@gmail.com wrote: On Thu, Jul 17, 2014 at 1:02 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: RFC for this is created. https://wiki.php.net/rfc/use-php_mt_rand New rand() function name is TBD. I cannot think of good name, but I like rand_system(). rand() may stay as it is now also. I have mixed feelings about that. What did change since our last discussions? What are the benefits to do it now? Also I really do no think it is worse the effort and the addition to do it in 5.x. Yes, there are still apps out there relying on rand only for areas where it should not be used, but how is it our problem? I mean: the documentation is clear, have been updated and clarified many times. I'd rather focus on doing one set of APIs for RNG for php6 and leave that untouch for now. Would like me to address RNG? It's ok for me. This is not a critical issue. I don't mind at all to postpone this change. I'll wait to finish RNG implementation, then decide what we will do for this. I would like to finish session related changes first. (Most critical issue will be addressed in session-ng, though) Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
-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)
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)
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)
- 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] intdiv()
On 17 Jul 2014, at 10:24, Nikita Popov nikita@gmail.com wrote: This is already what is currently happening, see http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_operators.c#1067. Andreas proposal is only useful in the case that the numbers don't divide exactly and you need round-down/truncation behavior and your numbers are in a range where the indirection through double arithmetic results in precision loss. It’s still useful regardless as it saves you implementing it in terms of floats. I mean, you can implement a right shift (rarely used outside bit masks) in terms of multiplication and exponentiation, but that doesn’t mean you shouldn’t have a right shift. -- 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 July 2014 23:16, Tjerk Meesters tjerk.meest...@gmail.com wrote: On Thu, Jul 17, 2014 at 10:25 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Tjerk, On Thu, Jul 17, 2014 at 11:09 AM, Tjerk Meesters tjerk.meest...@gmail.com wrote: Why should `password_verify()` work on a hash that wasn't generated with `password_hash()`? The fact that it uses `crypt()` internally should not leak outside of its API, imho. password_*() is designed as crypt() wrapper and this fact is documented since it was released. Obsolete password hash is easy to verify with password_needs_rehash(). Developers can check password database easily with password_needs_rehash(). The documentation states that the `hash` argument to both `password_needs_rehash()` and `password_verify()` is: hash - A hash created by password_hash(). Whoa. Don't put too much stock in that — I think I made that up out of whole cloth while trying to get _something_ into the manual for one of the early alpha releases of 5.5, and it wasn't intended as a restrictive statement. Passing a value from your own crypt() implementation may work, but that shouldn't be relied upon. I certainly wouldn't classify it as a problem that should be fixed in the password api. The original RFC specified that both crypt() and password_hash() hashes were accepted here, and that's probably what the documentation should say too. Adam -- 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 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)
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] crypt() BC issue
All, Look at the issue, there's a line in there that is the crux of the issue: So problem isn't only in ROUNDS_MIN. In fact, the overall algorithm changed. Look at a quick example: http://3v4l.org/Eov3o From 5.3.2+ (when we pulled in our own implementation of crypt-sha256 and crypt-sha512, and crypt-blowfish): using salt: string(31) $6$rounds=1000$abcdefghijklmnop gives hash: string(118) $6$rounds=1000$abcdefghijklmnop$SgL/Atu7DClkX0qBUuG6FS2bRf2XmLFWY9b8pRttPEj9ZSh4MKE5bKlz4WAKomLuWI.YQ5oIPLO2L.0OioAeW/ great. But in 4.3.0 - 5.2.17: the same salt gives: string(99) $6$rounds=10$EdPD9pXG2vAIeeyG2E/9Mzey2mA/qZgIBAbccXWtrNiymhFYXNK4r2gphMi4KOksXRubHnBWGVh/p2pP2D3R.. Which is shorter. Also note that the rounds went from the defined 1000, to 10. Things get far weirder: http://3v4l.org/KZoIv $h1='$6$rounds=1$abcdefghijklmnop'; $h2='$6$abcdefghijklmnop'; gives us (on 4.3.0 - 5.2.17): string(102) $6$rounds=1000$$6TFP.7u1vZP5A9fccvmUPteI8f29BLhgfqL1XEQqcrvqTSKKw5SBa2qw1sOwLEQ41Dhl1u/Jbi2hRHRYCdxuv0 string(99) $6$abcdefghi$4Dv/xQG4euniWsyrRHGUrNqM9CFl5Pg9EI88OgO4tIzuV952JnT09wVxrzUP9l/dr0wP3YSs1Ufz1qJpifLAA0 Note that these are different all around from the other results from the same version range. Basically, the version of crypt being linked to is either buggy (not likely) or our documentation of it is (likely). And our implementation (since 5.3.2) conforms to our documentation instead of the old behavior. Considering 5.3.2 was released 4 years ago, and 5.2 has been EOL for 3.5 years, I don't think there's anything that can be done about this. If it was a simple limit that needed changing, a polyfill would be easy (took me 10 minutes: https://gist.github.com/ircmaxell/ac0710ce044504f65cf0 ). But seeing the entire algorithm is different, much harder. I think this should be documented, and then called a day. I don't see anything else that could reasonably be done (changing crypt() at this point is out of the question IMHO). - Add bool crypt_migration INI that is default to OFF for PHP 5.4 and up. - master will not have this INI. Please don't. As I showed above, it's already long past that point. And we don't need new ini settings. And what that ini setting would control is not the minimum iteration flag (as that's not the only problem), but which version of libcrypt we're binding to (our internal one, or an external one). Which means that the overall behavior *will* change. And unless you do it perfectly, it could effect all of crypts algorithms (potentially impacting password_hash, etc). We internalized the algorithms in 5.3.2 at least partially because the system provided libraries were inconsistent at best (hence why many but not all 5.2 systems don't support bcrypt, it depended on the build of libcrypt you linked against). Please don't make us re-live this inconsistency... Especially when it won't really solve the problem. Regarding password_verify() accepting crypt(), I consider it an implementation detail that it works. I know the RFC specifies it, but it specifies it not as a conceptual fact (that it will always be no more than a reason to be there), but more as an explanation for what it's currently doing. I would not rely on that fact. It may work today. It may work tomorrow, but it shouldn't be documented as such (as it's the complement of password_hash(), not the complement of crypt()). As far as I'm aware, the only reason for not marking crypt() E_DEPRECATED right now is for compatibility with external systems, and as far as those go, changing a default won't effect anything. I want to reinforce that point, because it's spot on the money: I think crypt should live on. password_hash should be the way new systems are built, sure. But as you mention external systems, crypt should be a standard way of interacting with them (heck, that's what the lib was designed for). It shouldn't be a if you're not using password_hash(), you're doing it wrong. It's password_hash() should solve the majority of use-cases, but if you have a different need, there are other options. My $0.02 Anthony On Thu, Jul 17, 2014 at 1:50 PM, Adam Harvey ahar...@php.net wrote: On 16 July 2014 23:16, Tjerk Meesters tjerk.meest...@gmail.com wrote: On Thu, Jul 17, 2014 at 10:25 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Tjerk, On Thu, Jul 17, 2014 at 11:09 AM, Tjerk Meesters tjerk.meest...@gmail.com wrote: Why should `password_verify()` work on a hash that wasn't generated with `password_hash()`? The fact that it uses `crypt()` internally should not leak outside of its API, imho. password_*() is designed as crypt() wrapper and this fact is documented since it was released. Obsolete password hash is easy to verify with password_needs_rehash(). Developers can check password database easily with password_needs_rehash(). The documentation states that the `hash` argument to both `password_needs_rehash()` and `password_verify()` is: hash - A hash created by password_hash().
[PHP-DEV] VCS Account Request: royopa
Hi I want to help translating the PHP documentation. For some time I have contributed in PHP translation projects for Symfony2 (https://github.com/andreia/symfony-docs-pt-BR/), DBAL (https://github.com/royopa/dbal-documentation- en_US) and Silex Framework (https://github.com/royopa/silex-documentation-pt_BR) for the language pt_BR. I also contribute to the translation of DSpace (https://github.com/DSpace/dspace-xmlui-lang) project. I have attended many events of PHP, including PHP Conference Brazil 2010 and 2011 and PHP Test Fest 2010 and 2014 inclusive I have some tests published in PHP 5.2. In Sao Paulo, I have participated in events and meetups in order to contribute to the PHP community. Rodrigo Prado de Jesus http://about.me/royopa -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] crypt() BC issue
Hi all, On Fri, Jul 18, 2014 at 4:38 AM, Anthony Ferrara ircmax...@gmail.com wrote: We internalized the algorithms in 5.3.2 at least partially because the system provided libraries were inconsistent at best (hence why many but not all 5.2 systems don't support bcrypt, it depended on the build of libcrypt you linked against). Please don't make us re-live this inconsistency... Especially when it won't really solve the problem. OK for me. I suggested to close the bug as 'wont fix' in first place. Regarding password_verify() accepting crypt(), I consider it an implementation detail that it works. I know the RFC specifies it, but it specifies it not as a conceptual fact (that it will always be no more than a reason to be there), but more as an explanation for what it's currently doing. I would not rely on that fact. It may work today. It may work tomorrow, but it shouldn't be documented as such (as it's the complement of password_hash(), not the complement of crypt()). As far as I'm aware, the only reason for not marking crypt() E_DEPRECATED right now is for compatibility with external systems, and as far as those go, changing a default won't effect anything. I want to reinforce that point, because it's spot on the money: I think crypt should live on. password_hash should be the way new systems are built, sure. But as you mention external systems, crypt should be a standard way of interacting with them (heck, that's what the lib was designed for). It shouldn't be a if you're not using password_hash(), you're doing it wrong. It's password_hash() should solve the majority of use-cases, but if you have a different need, there are other options. I agree. crypt() should be available as normal function. Anthony, do you have suggestion for removing 72 char restriction of PASSWORD_BCRYPT? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] crypt() BC issue
Yasuo Anthony, do you have suggestion for removing 72 char restriction of PASSWORD_BCRYPT? My suggestion is to leave it there (it's no longer bcrypt if you do something to remove it). Here's a deeper explanation: http://stackoverflow.com/a/16597402/338665 Once scrypt (or yescrypt, or whatever comes out of PHC) gets crypt(3) bindings, then we can implement that and pull it into the password API. Until then, implementing anything else is a step backwards (crypt-sha256/512 is weaker than bcrypt, as is PBKDF2+sha512). So since the 72 character restrict has little if any practical effect (see my answer above), it's not worth making a practical weakening (measurably harming everyone) of the overall algorithm for no reason. My assertion is that, for the average developer, they are far more likely to screw something up than actually improve security. The documentation should be updated (and was, but instead of fixing a misleading line, someone simply removed it, making the overall statement more misleading). Could we pre-hash internally ourselves? Sure. But at that point it's no longer bcrypt (but our own hybrid) which was not what we were after. My stance here is that password_hash() should use standard algorithms and formats **only**. The last thing we should be doing is inventing crypto ourselves. Even if it seems safe. Even if it seems better. Let's stick with the current implementation, make the 72 character warning a lot less scary, and move on. Once there are crypt(3) bindings to a more secure algorithm (again, scrypt or yescrypt, or whatever), then move to it Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] intdiv()
On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds a...@ajf.me wrote: On 17 Jul 2014, at 10:24, Nikita Popov nikita@gmail.com wrote: This is already what is currently happening, see http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_operators.c#1067. Andreas proposal is only useful in the case that the numbers don't divide exactly and you need round-down/truncation behavior and your numbers are in a range where the indirection through double arithmetic results in precision loss. It’s still useful regardless as it saves you implementing it in terms of floats. I mean, you can implement a right shift (rarely used outside bit masks) in terms of multiplication and exponentiation, but that doesn’t mean you shouldn’t have a right shift. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php There seems to be a pretty even split on this. Personally, I'm a +1 for it. PHP has tons of obscure, rarely used functions. Even if the gain is relatively minor, there's really no cost that I can think of. So from a cost-benefit standpoint, even a minor improvement is still desirable when there's no practical downside to it. Given the number of options that are coming up, I'd suggest you break the RFC down into two votes: A simple yes/no vote followed by an if yes, how should it be implemented? vote with the various options (the operators, functions, etc). If the RFC passes, then whichever option got a plurality of the votes would be the implemented option. So yeah, I'd say bring it to a vote and that'll settle it one way or another. --Kris
Re: [PHP-DEV] [RFC] intdiv()
On Fri, Jul 18, 2014 at 10:47 AM, Kris Craig kris.cr...@gmail.com wrote: On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds a...@ajf.me wrote: On 17 Jul 2014, at 10:24, Nikita Popov nikita@gmail.com wrote: This is already what is currently happening, see http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_operators.c#1067. Andreas proposal is only useful in the case that the numbers don't divide exactly and you need round-down/truncation behavior and your numbers are in a range where the indirection through double arithmetic results in precision loss. It’s still useful regardless as it saves you implementing it in terms of floats. I mean, you can implement a right shift (rarely used outside bit masks) in terms of multiplication and exponentiation, but that doesn’t mean you shouldn’t have a right shift. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php There seems to be a pretty even split on this. Personally, I'm a +1 for it. PHP has tons of obscure, rarely used functions. Even if the gain is relatively minor, there's really no cost that I can think of. So from a cost-benefit standpoint, even a minor improvement is still desirable when there's no practical downside to it. Given the number of options that are coming up, I'd suggest you break the RFC down into two votes: A simple yes/no vote followed by an if yes, how should it be implemented? vote with the various options (the operators, functions, etc). If the RFC passes, then whichever option got a plurality of the votes would be the implemented option. This makes it more complicated because a language change requires 2/3 majority while a new function requires 50% + 1. To make things simpler - and I believe it had been proposed before - the main vote should include the implementation as a function and the secondary vote should be for the operator. So yeah, I'd say bring it to a vote and that'll settle it one way or another. --Kris -- -- Tjerk
Re: [PHP-DEV] [RFC] intdiv()
On Thu, Jul 17, 2014 at 8:39 PM, Tjerk Meesters tjerk.meest...@gmail.com wrote: On Fri, Jul 18, 2014 at 10:47 AM, Kris Craig kris.cr...@gmail.com wrote: On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds a...@ajf.me wrote: On 17 Jul 2014, at 10:24, Nikita Popov nikita@gmail.com wrote: This is already what is currently happening, see http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_operators.c#1067. Andreas proposal is only useful in the case that the numbers don't divide exactly and you need round-down/truncation behavior and your numbers are in a range where the indirection through double arithmetic results in precision loss. It’s still useful regardless as it saves you implementing it in terms of floats. I mean, you can implement a right shift (rarely used outside bit masks) in terms of multiplication and exponentiation, but that doesn’t mean you shouldn’t have a right shift. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php There seems to be a pretty even split on this. Personally, I'm a +1 for it. PHP has tons of obscure, rarely used functions. Even if the gain is relatively minor, there's really no cost that I can think of. So from a cost-benefit standpoint, even a minor improvement is still desirable when there's no practical downside to it. Given the number of options that are coming up, I'd suggest you break the RFC down into two votes: A simple yes/no vote followed by an if yes, how should it be implemented? vote with the various options (the operators, functions, etc). If the RFC passes, then whichever option got a plurality of the votes would be the implemented option. This makes it more complicated because a language change requires 2/3 majority while a new function requires 50% + 1. To make things simpler - and I believe it had been proposed before - the main vote should include the implementation as a function and the secondary vote should be for the operator. So yeah, I'd say bring it to a vote and that'll settle it one way or another. --Kris -- -- Tjerk The problem is that, since that suggestion, other variations have been proposed with no clear favorite. How should we decide *which* proposed operator, for example? There have been several mentioned. --Kris
Re: [PHP-DEV] [RFC] intdiv()
On Fri, Jul 18, 2014 at 12:04 PM, Kris Craig kris.cr...@gmail.com wrote: On Thu, Jul 17, 2014 at 8:39 PM, Tjerk Meesters tjerk.meest...@gmail.com wrote: On Fri, Jul 18, 2014 at 10:47 AM, Kris Craig kris.cr...@gmail.com wrote: On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds a...@ajf.me wrote: On 17 Jul 2014, at 10:24, Nikita Popov nikita@gmail.com wrote: This is already what is currently happening, see http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_operators.c#1067. Andreas proposal is only useful in the case that the numbers don't divide exactly and you need round-down/truncation behavior and your numbers are in a range where the indirection through double arithmetic results in precision loss. It’s still useful regardless as it saves you implementing it in terms of floats. I mean, you can implement a right shift (rarely used outside bit masks) in terms of multiplication and exponentiation, but that doesn’t mean you shouldn’t have a right shift. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php There seems to be a pretty even split on this. Personally, I'm a +1 for it. PHP has tons of obscure, rarely used functions. Even if the gain is relatively minor, there's really no cost that I can think of. So from a cost-benefit standpoint, even a minor improvement is still desirable when there's no practical downside to it. Given the number of options that are coming up, I'd suggest you break the RFC down into two votes: A simple yes/no vote followed by an if yes, how should it be implemented? vote with the various options (the operators, functions, etc). If the RFC passes, then whichever option got a plurality of the votes would be the implemented option. This makes it more complicated because a language change requires 2/3 majority while a new function requires 50% + 1. To make things simpler - and I believe it had been proposed before - the main vote should include the implementation as a function and the secondary vote should be for the operator. So yeah, I'd say bring it to a vote and that'll settle it one way or another. --Kris -- -- Tjerk The problem is that, since that suggestion, other variations have been proposed with no clear favorite. How should we decide *which* proposed operator, for example? There have been several mentioned. If the author can't settle on a particular operator, then a third vote would be necessary for those who vote to have an operator in the first place; perhaps a simple majority required for that. --Kris -- -- Tjerk
Re: [PHP-DEV] [RFC] intdiv()
On Thu, Jul 17, 2014 at 9:18 PM, Tjerk Meesters tjerk.meest...@gmail.com wrote: On Fri, Jul 18, 2014 at 12:04 PM, Kris Craig kris.cr...@gmail.com wrote: On Thu, Jul 17, 2014 at 8:39 PM, Tjerk Meesters tjerk.meest...@gmail.com wrote: On Fri, Jul 18, 2014 at 10:47 AM, Kris Craig kris.cr...@gmail.com wrote: On Thu, Jul 17, 2014 at 6:31 AM, Andrea Faulds a...@ajf.me wrote: On 17 Jul 2014, at 10:24, Nikita Popov nikita@gmail.com wrote: This is already what is currently happening, see http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_operators.c#1067. Andreas proposal is only useful in the case that the numbers don't divide exactly and you need round-down/truncation behavior and your numbers are in a range where the indirection through double arithmetic results in precision loss. It’s still useful regardless as it saves you implementing it in terms of floats. I mean, you can implement a right shift (rarely used outside bit masks) in terms of multiplication and exponentiation, but that doesn’t mean you shouldn’t have a right shift. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php There seems to be a pretty even split on this. Personally, I'm a +1 for it. PHP has tons of obscure, rarely used functions. Even if the gain is relatively minor, there's really no cost that I can think of. So from a cost-benefit standpoint, even a minor improvement is still desirable when there's no practical downside to it. Given the number of options that are coming up, I'd suggest you break the RFC down into two votes: A simple yes/no vote followed by an if yes, how should it be implemented? vote with the various options (the operators, functions, etc). If the RFC passes, then whichever option got a plurality of the votes would be the implemented option. This makes it more complicated because a language change requires 2/3 majority while a new function requires 50% + 1. To make things simpler - and I believe it had been proposed before - the main vote should include the implementation as a function and the secondary vote should be for the operator. So yeah, I'd say bring it to a vote and that'll settle it one way or another. --Kris -- -- Tjerk The problem is that, since that suggestion, other variations have been proposed with no clear favorite. How should we decide *which* proposed operator, for example? There have been several mentioned. If the author can't settle on a particular operator, then a third vote would be necessary for those who vote to have an operator in the first place; perhaps a simple majority required for that. --Kris -- -- Tjerk Hmm ok that sounds reasonable. --Kris
Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
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
