Re: [PHP-DEV] PHP 5.4.16 and PHP 5.3.26 released!
Stas Malyshev wrote: >Hi! > >> be great. (Perfect would be if that script would also translate NEWS >> to HTML, see README.RELEASE_PROCESS for HTML requirements .. even > >Something like this: https://gist.github.com/smalyshev/5736464 > >If it looks good, I'll add it into phpWeb/bin. Please also add html escaping for the entry (some entres contain i.e. "->") And then we'd need a volunteer to do the bug visibility check (bugweb/www/rpc.php or bugweb/www/rss/* might be good starting points for an API for that) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Apparmor change_hat functionality for php-fpm
https://wiki.php.net/rfc/fpm_change_hat
RE: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
From: Nikita Popov [mailto:nikita@gmail.com] Sent: Sunday, June 09, 2013 5:15 PM To: Zeev Suraski Cc: PHP internals Subject: Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements On Sun, Jun 9, 2013 at 3:37 PM, Zeev Suraski wrote: >> What I meant by cumulativity in that context is really commutativity ☺ >> Fixed (and also added transitivity). >> >> In other words, operands that are commutative in PHP (like addition, >> multiplication, etc.) – one should not overload for domains where they’re >> not commutative. > > Why? Mostly because I don't want us to have to worry about this when implementing the engine. It might side effects on optimizations that are valid when dealing with standard values - but not when dealing with these complex values. That said, you brought up a couple of examples where we already have different behaviors for $a+$b and $b+$a, so this point might be moot (mostly referring to the array part, I have a harder time accepting the floating point assertion although I understand why you're saying it...) > That's why I'm not sure it makes sense to have "too strict" definitions > for what is a valid overload and what isn't. I think "limited to cases > where there are clear definitions to > the behavior of all overloaded > operators" and "should be for mathematical use cases only" are enough as > guidelines :) I guess I can live with that (if nobody has any other additional thoughts on what we might be missing here). I can say that I mostly heard horror stories about operator overloading from my old C++ days - which is why I want us to do our best to avoid creating the same pitfalls in PHP. I do think that clear extension-level operator overloading support can be quite useful in some cases though (like gmp/bcmath). Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
On Sun, Jun 9, 2013 at 3:37 PM, Zeev Suraski wrote: > What I meant by cumulativity in that context is really commutativity J > Fixed (and also added transitivity). > > > > In other words, operands that are commutative in PHP (like addition, > multiplication, etc.) – one should not overload for domains where they’re > not commutative. > > > > Zeev > Why? For example matrix multiplication is not commutative, but I would still consider writing $matrixA * $matrixB a valid application of overloading. Non-commutative multiplication operations aren't uncommon (that's why a mathematical ring only requires the addition operator to be commutative). The same also applies the other way around: For example PHP's default + operator is *not* commutative (when used on arrays) and both + and * are non-associative and non-distributive (floating point arithmetic), but you'd probably still expect those properties from an overloaded +/- operator. That's why I'm not sure it makes sense to have "too strict" definitions for what is a valid overload and what isn't. I think "limited to cases where there are clear definitions to the behavior of all overloaded operators" and "should be for mathematical use cases only" are enough as guidelines :) Thanks, Nikita
RE: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
What I meant by cumulativity in that context is really commutativity J Fixed (and also added transitivity). In other words, operands that are commutative in PHP (like addition, multiplication, etc.) – one should not overload for domains where they’re not commutative. Zeev *From:* Nikita Popov [mailto:nikita@gmail.com] *Sent:* Sunday, June 09, 2013 4:20 PM *To:* Zeev Suraski *Cc:* PHP internals *Subject:* Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements On Sun, Jun 9, 2013 at 10:00 AM, Zeev Suraski wrote: It wouldn’t have been the first time that something that seems common sense, suddenly becomes controversial a few years later J Better safe than sorry. I made some changes to the phrasing of the final paragraph in this section (please review and make sure you’re good with it) – I think the list you added is great. Looks good. One question though, what do you mean by "cumulativity" in that context? Nikita
Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
On Sun, Jun 9, 2013 at 10:00 AM, Zeev Suraski wrote: > It wouldn’t have been the first time that something that seems common > sense, suddenly becomes controversial a few years later J Better safe > than sorry. > > I made some changes to the phrasing of the final paragraph in this section > (please review and make sure you’re good with it) – I think the list you > added is great. > Looks good. One question though, what do you mean by "cumulativity" in that context? Nikita
RE: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
It wouldn’t have been the first time that something that seems common sense, suddenly becomes controversial a few years later J Better safe than sorry. I made some changes to the phrasing of the final paragraph in this section (please review and make sure you’re good with it) – I think the list you added is great. Thanks, Zeev *From:* Nikita Popov [mailto:nikita@gmail.com] *Sent:* Saturday, June 08, 2013 3:54 PM *To:* Zeev Suraski *Cc:* Dmitry Stogov; PHP internals *Subject:* Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements On Fri, Jun 7, 2013 at 9:45 PM, Zeev Suraski wrote: I would add that the purpose of this feature would be exclusive to extensions that implement mathematical concepts, where the operators are well defined. In other words, arbitrary precision math, vectors, matrices, etc. - yes; Incrementing or decrementing a picture object to change the white balance - no. This seems like common sense... But just to be sure I added a note (and your example) at the end of the https://wiki.php.net/rfc/operator_overloading_gmp#applications_of_operator_overloadingsection :) Nikita
