Re: [PHP-DEV] RFC: Move phpng to master
On 27 07 2014, at 02:53, Kris Craig kris.cr...@gmail.com wrote: So even IF you want to reduce the scope of the 2/3 requirement to language impacts in userland only, your RFC *still* falls under that requirement because it directly affects the language itself in userland, as described above. I would again invite you to reconsider your position on this and avoid a protracted fight on this that would only serve to split the community. I’m actually not sure why we even have to vote on PHP-NG? How about for the crusaders to build something comparable to put up to vote against PHP-NG? There isn’t? Well, then let’s go ahead. Simple. Rolling eyes, Mike PS: My dog wants voting rights because he feels like he’ll be affected by changes to PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Sat, Jul 26, 2014 at 11:10 PM, Michael Wallner mike.php@gmail.com wrote: On 27 07 2014, at 02:53, Kris Craig kris.cr...@gmail.com wrote: So even IF you want to reduce the scope of the 2/3 requirement to language impacts in userland only, your RFC *still* falls under that requirement because it directly affects the language itself in userland, as described above. I would again invite you to reconsider your position on this and avoid a protracted fight on this that would only serve to split the community. I’m actually not sure why we even have to vote on PHP-NG? How about for the crusaders to build something comparable to put up to vote against PHP-NG? There isn’t? Well, then let’s go ahead. Simple. To answer your question (sort-of), the alternative to PHP-NG is what we have right now. I can't speak for anyone else, of course, but I certainly am not opposed to PHP-NG, even though Zeev seems to think so. I just don't think it's ready to be merged into master yet, based on everything I've seen, including concerns raised by others more knowledgeable than I on this list. I also just want to make sure something so massive in scope isn't pushed through by a slim majority, especially since doing so would violate the Voting RFC as it's currently written and would probably lead to an ugly fight among those who have RW+ access. I actually like PHP-NG and what it strives to do. I just think its developers are jumping the gun and trying to force something through that many in the community feel is not yet ready for deployment. I honestly don't understand why there's such a rush and why people who are calling for things to slow down so that cooler heads can prevail are being demonized and mocked. It's not you're either with us or you're against us. I don't oppose PHP-NG simply because I want to make sure all the ducks are in a row before it's deployed. Here's my question to counter yours, Michael: What's the rush? --Kris
Re: [PHP-DEV] RFC: Move phpng to master
On Sun, Jul 27, 2014 at 8:10 AM, Michael Wallner mike.php@gmail.com wrote: On 27 07 2014, at 02:53, Kris Craig kris.cr...@gmail.com wrote: So even IF you want to reduce the scope of the 2/3 requirement to language impacts in userland only, your RFC *still* falls under that requirement because it directly affects the language itself in userland, as described above. I would again invite you to reconsider your position on this and avoid a protracted fight on this that would only serve to split the community. I’m actually not sure why we even have to vote on PHP-NG? As it is surely a rhetoric question, let leave it, ok? How about for the crusaders to build something comparable to put up to vote against PHP-NG? There isn’t? Well, then let’s go ahead. Simple. Rolling eyes, Mike PS: My dog wants voting rights because he feels like he’ll be affected by changes to PHP. This kind of post surely brings us a huge step forward. 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] Problems with the fix for the BC break introduced in 5.4.29 and 5.5.13
Hi!
It would be good to have a section in UPGRADING.INTERNALS explaining
in details what should be done, very important for non core extensions
(pecl or other repositories).
Probably a good idea but I'm not sure what exactly to write there,
besides initialize everything, check everything :) There are many
places (esp. in SPL, but not only) where checks are present in some
methods, but not others, or some values are checked while others do not,
there are also places where some checks produce errors and some
exceptions, sometimes even within one class. We don't need to clean that
up right now but it's a good idea to keep in mind we need to.
There's also a more tricky problem since many clone functions don't do
the right thing too. E.g. this script:
class MyPDO extends PDO { function __construct() {} }
$pdo = new MyPDO();
$pdo2 = clone $pdo;
$pdo2-query(123);
Produces a segfault, even though without clone it works fine. I wonder
if one overrides __clone wouldn't more things break.
I wrote a simple fuzzer to test classes, here:
https://gist.github.com/smalyshev/f4d0c1502fa2411478ff
Note: it runs random functions with random arguments, so don't run it
anywhere it could hurt real data.
--
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: Move phpng to master
On 27 Jul 2014 08:23, Kris Craig kris.cr...@gmail.com wrote: Here's my question to counter yours, Michael: What's the rush? Every day php-ng is not GA, PHP is losing ground to its competitors. People seem to ignore this because of cosmetics.
Re: [PHP-DEV] RFC: Move phpng to master
On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner mike.php@gmail.com wrote: On 27 Jul 2014 08:23, Kris Craig kris.cr...@gmail.com wrote: Here's my question to counter yours, Michael: What's the rush? Every day php-ng is not GA, PHP is losing ground to its competitors. Umm, how? Do you have any data to support this? According to http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing. As far as our competitors are concerned, well: http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python As you can see, PHP continues to dominate with over 80% market share and no signs-- at least, none that I can see-- that we are losing ground as you stated. So again: What's the rush? --Kris
Re: [PHP-DEV] RFC: Move phpng to master
On 27/07/14 07:23, Kris Craig wrote: Here's my question to counter yours, Michael: What's the rush? I think that the only 'objection' I have to 'simply' merging phpng is that it is not just a 'single' change? This vote is all or nothing, so every change is bundled without a vote on particular elements. That many elements ARE simply improvements to the speed at which things are processed is not the problem here, and it may well be that the changes that do affect BC have a practical justification, but there will not be a discussion on that? I'm currently fighting a problem due to a blanket change to a number of systems, which offer a vast speed improvement, but now apparently make it impossible to identify the location of the client machine. The change to VDI is a done deal but nobody on site seems to be interested in fixing the resulting problem :( Due diligence would have addressed the problem beforehand and could well have steered things a different way. The 'rush' with phpng is that people need to have a stable base to be working with, and if php-next is to be phpng, then we need to be working with it. If I magically found some spare time today should I be looking at the current code base or phpng going forward? Documentation IS crucial here, and documenting those changes and providing information where an individual change affects BC is essential, but there should be some mechanism to review elements that are not so clear cut? IS_BOOL object container against IS_TRUE and IS_FALSE new values is probably not a good example, but it is a change that I don't currently see full rational behind ... if I create a bool container I don't know which value it is ... We do not want to complicate things by voting on each element, but it's the simple fact that so many elements have been re-engineered without the normal process that is causing irritation, so some agreement that if questions are raised about an element then it WILL get a proper discussion and if justified get reverted? I think that this is part of the debate on 2/3rds or 50-50 ... there are elements which would normally be a 2/3rds decision? So there should be an agreement that these can be reviewed again later? -- 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: Move phpng to master
On 27/07/14 08:26, Kris Craig wrote: As you can see, PHP continues to dominate with over 80% market share and no signs-- at least, none that I can see-- that we are losing ground as you stated. So again: What's the rush? Especially since 75% of that are still on PHP5.3 or 5.2 ;) But I had forgotten the comparison has a breakdown by ranking. I made the unsubstantiated comment about big sites not using PHP which of cause this shows, but there is no reference to the alternative PHP engines? One question that does come too mind is Why is python so popular with the bigger sites? Is it because compiled builds are fully supported? Certainly if any of my own sites traffic started to take off I would be looking down that avenue, so while improving the speed of interpreted working is important, it is still stability in the language that blocks uptake? -- 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: Move phpng to master
On 27 Jul 2014 09:26, Kris Craig kris.cr...@gmail.com wrote: On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner mike.php@gmail.com wrote: On 27 Jul 2014 08:23, Kris Craig kris.cr...@gmail.com wrote: Here's my question to counter yours, Michael: What's the rush? Every day php-ng is not GA, PHP is losing ground to its competitors. Umm, how? Do you have any data to support this? According to http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing. As far as our competitors are concerned, well: http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python As you can see, PHP continues to dominate with over 80% market share and no signs-- at least, none that I can see-- that we are losing ground as you stated. Surely it's wise to make the same wrong assumptions Microsoft did with Internet Explorer?
Re: [PHP-DEV] [VOTE] RFC: Catchable call to a member function of a non-object
Hi Timm, On Sun, Jun 29, 2014 at 7:40 PM, Timm Friebe p...@thekid.de wrote: a couple of weeks ago, I proposed a change to the handling of the situation where methods are called on non-objects. Instead of an E_ERROR, the engine would raise an E_RECOVERABLE_ERROR, and enable framework and library authors to handle this. An intriguing usecase from my POV is to make use of this in tools like PHPUnit; instead of just printing a fatal error in the middle of a test run and exiting, the tools can decide to raise an exception and display the very much more helpful backtrace. No third-party PHP extensions needed for this, just a simple set_error_handler() call [1]. I've verified various places like phpdbg and added a bunch of tests and am glad to extend that should anyone come up with a situation he/she feel this would behave in an unstable manner; athough this is realized in a somewhat similar manner to type hint mismatches, which have proven to be quite stable. Anyhow, I'd now like to see where we'd come out at and would kindly ask you to vote for or against inclusion of this feature: https://wiki.php.net/rfc/catchable-call-to-member-of-non-object#vote Thanks in advance! I like the idea. Only thing that I don't like is it depends on error message to be useful rather than error code/status. Was this discussed? Just curious. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Weird constant expression syntax and bug
On Sun, Jul 27, 2014 at 12:02 AM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
Could somebody please clarify what issues are still open here? From what
I understand, both the opcache issue and the recursion issue are fixed
now. What's the discussion about?
As I understand, the issue is that if you define class constant like this:
class Foo { const Bar = [0]; }
everything works fine. But if you do var_dump(Foo::Bar), it bombs out
with fatal error (the same goes for every other usage of that constant
in expression). Please correct me if my info is outdated, but I think it
is a behavior that should not be left in the release. If for some reason
we can't make array constants work normally, we should just omit them
altogether.
Yes, I agree that this is not correct behavior - and I don't really
understand why it was introduced and why it isn't trivial to fix. PHP-5.5
had a check for this case in place (
http://lxr.php.net/xref/PHP_5_5/Zend/zend_compile.c#7071) and phpng
contains an AST-compatible variant of the array check (
http://lxr.php.net/xref/phpng/Zend/zend_compile.c#7776). Shouldn't copying
the condition from phpng into PHP-5.6 resolve this issue?
Nikita
Re: [PHP-DEV] Weird constant expression syntax and bug
Hi! Yes, I agree that this is not correct behavior - and I don't really understand why it was introduced and why it isn't trivial to fix. PHP-5.5 had a check for this case in place (http://lxr.php.net/xref/PHP_5_5/Zend/zend_compile.c#7071) and phpng contains an AST-compatible variant of the array check (http://lxr.php.net/xref/phpng/Zend/zend_compile.c#7776). Shouldn't copying the condition from phpng into PHP-5.6 resolve this issue? I agree it should be easy to fix it this way, but I'd like for Bob to provide a bit more input here as to best way to resolve it. I'm not sure why usage of arrays in runtime is disallowed now in 5.6 code, so I'm not sure if we should enable it or remove it. If we don't find another way soon, I guess porting one from phpng is what we'll have to do. -- 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] [VOTE] RFC: Catchable call to a member function of a non-object
Hello, Yasuo Ohgaki yohg...@ohgaki.net hat am 27. Juli 2014 um 10:11 geschrieben: Hi Timm, On Sun, Jun 29, 2014 at 7:40 PM, Timm Friebe p...@thekid.de mailto:p...@thekid.de wrote: a couple of weeks ago, I proposed a change to the handling of the situation where methods are called on non-objects. Instead of an E_ERROR, the engine would raise an E_RECOVERABLE_ERROR, and enable framework and library authors to handle this. [...] I like the idea. Only thing that I don't like is it depends on error message to be useful rather than error code/status. Was this discussed? Just curious. No, this wasn't discussed so far. You're right, this could make the code inside the error handler more readable and robust. It would mean, however, changing all the other E_RECOVERABLE_ERRORs too, like argument type mismatching and certain closure and generator operations; and thus was out of scope. I remember this from a couple of years back though; but can't recall why it was never done. -Timm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
On Sun, Jul 27, 2014 at 1:03 AM, Michael Wallner mike.php@gmail.com wrote: On 27 Jul 2014 09:26, Kris Craig kris.cr...@gmail.com wrote: On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner mike.php@gmail.com wrote: On 27 Jul 2014 08:23, Kris Craig kris.cr...@gmail.com wrote: Here's my question to counter yours, Michael: What's the rush? Every day php-ng is not GA, PHP is losing ground to its competitors. Umm, how? Do you have any data to support this? According to http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing. As far as our competitors are concerned, well: http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python As you can see, PHP continues to dominate with over 80% market share and no signs-- at least, none that I can see-- that we are losing ground as you stated. Surely it's wise to make the same wrong assumptions Microsoft did with Internet Explorer? Again, where's your evidence, Michael? I provided two separate sources that provide data showing that PHP is *gaining* market share and continues to dominate over the competition, which directly contradicts the claim you made. Simply brushing this factual data as wrong assumptions-- without any data of your own to back-up that claim-- does not constitute a valid counter-argument, nor does introducing a non sequitur by comparing PHP to Internet Explorer. These aren't assumptions, wrong or otherwise. This is data pulled from reliable sources. If you have separate data that calls it into question, then please share it with us. Otherwise, you're just making baseless and factually inaccurate claims about PHP to justify your argument about PHP-NG. As far as I can tell from the evidence available, your statement that PHP is losing ground to its competitors appears to be false. In fact, the exact opposite appears to be true. Again, that's not an assumption. That's just looking at the available data. --Kris
Re: [PHP-DEV] RFC: Move phpng to master
On 27 07 2014, at 11:44, Kris Craig kris.cr...@gmail.com wrote: [a lot] Maybe because you see those as competitors, but I see HHVM and friends as current competitors, being evaluated to replace stock PHP, which is definitely not covered by any nice statistics you can currently view. Cheers, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Weird constant expression syntax and bug
Am 27.7.2014 um 10:55 schrieb Stas Malyshev smalys...@sugarcrm.com: Hi! Yes, I agree that this is not correct behavior - and I don't really understand why it was introduced and why it isn't trivial to fix. PHP-5.5 had a check for this case in place (http://lxr.php.net/xref/PHP_5_5/Zend/zend_compile.c#7071) and phpng contains an AST-compatible variant of the array check (http://lxr.php.net/xref/phpng/Zend/zend_compile.c#7776). Shouldn't copying the condition from phpng into PHP-5.6 resolve this issue? I agree it should be easy to fix it this way, but I'd like for Bob to provide a bit more input here as to best way to resolve it. I'm not sure why usage of arrays in runtime is disallowed now in 5.6 code, so I'm not sure if we should enable it or remove it. If we don't find another way soon, I guess porting one from phpng is what we'll have to do. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ The AST compatible fix in phpng is just for top-level arrays, but not for something like constant ? [1] : [2]. I think we should just enable it, that would lower the level of confusion. I totally agree that current status isn't optimal. Bob
Re: [PHP-DEV] RFC: Move phpng to master
Instead of endless, useless bickering, how about everyone both for and against merging jump in and start helping with phpng (docs, api cleanup/stabilization, but fixes, etc)? Imagine how much more stable and ready to merge it would be if you concentrated the saber rattling energy towards actually accomplishing something. On Sun, Jul 27, 2014 at 6:00 AM, Michael Wallner mike.php@gmail.com wrote: On 27 07 2014, at 11:44, Kris Craig kris.cr...@gmail.com wrote: [a lot] Maybe because you see those as competitors, but I see HHVM and friends as current competitors, being evaluated to replace stock PHP, which is definitely not covered by any nice statistics you can currently view. Cheers, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] imagettf* deprecation/removal
Wouldn’t it be simpler to just make them aliases? Indeed, and as I have no problem if Lonny likes to go ahead with this RFC, I do not think we need one for such trivial change. Andrea, Whom are you suggesting the alias would be simpler for? Personally, I do not think it would be simpler for the userland API to have them aliased. I think an alias will cause unneeded confusion, discussions, and waste time in an office. Pierre, The idea behind making this an RFC is to come to an agreement on both the change and the timeline now so there are little/no questions later. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] imagettf* deprecation/removal
On Sun, Jul 27, 2014 at 7:09 PM, Lonny Kapelushnik lo...@lonnylot.com wrote: Wouldn’t it be simpler to just make them aliases? Indeed, and as I have no problem if Lonny likes to go ahead with this RFC, I do not think we need one for such trivial change. Andrea, Whom are you suggesting the alias would be simpler for? Personally, I do not think it would be simpler for the userland API to have them aliased. I think an alias will cause unneeded confusion, discussions, and waste time in an office. Pierre, The idea behind making this an RFC is to come to an agreement on both the change and the timeline now so there are little/no questions later. Yes, and I appreciate your work :) However the idea to add yet other warnings/notices to ext/gd is not something I like to see in GD. I will rather remove many for php-next instead of adding more. Also some new font APIs may as well make the whole ttf ones less relevant, see the upstream version. I will take a deeper look at the function you refer to and see what would fit best. If a documentation only deprecation works I will go for it. 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] imagettf* deprecation/removal
On 27 Jul 2014, at 18:09, Lonny Kapelushnik lo...@lonnylot.com wrote: Whom are you suggesting the alias would be simpler for? Personally, I do not think it would be simpler for the userland API to have them aliased. I think an alias will cause unneeded confusion, discussions, and waste time in an office. The API signatures are compatible, yes? In which case, just make the legacy functions be aliases of the new ones. This avoids breaking everyone’s code. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Language Specification
On 26/07/2014 22:55, Chris Wright wrote: On 25 July 2014 17:25, Larry Garfield la...@garfieldtech.com wrote: On 7/24/14, 2:38 PM, Sara Golemon wrote: On Thu, Jul 24, 2014 at 12:29 PM, Rowan Collins rowan.coll...@gmail.com wrote: Zend is only one of many contributors. Yes, the engine is still named Zend Engine but the language has been improved by many php.net contributors. The idea was that ZPHP is PHP running on top of the Zend Engine, in the same way that JRuby is Ruby running on top of the JVM, and CPython is Python implemented in C. In my mind, it doesn't imply any connection to the company of the same name - especially if we're only borrowing its first letter - but perhaps others would see that differently. We (HHVM) ran into this issue as well. We'd talk about the way PHP (the reference implementation) does something and needed to disambiguate it from PHP (the language syntax). Prior to my joining the project Zend was the go-to moniker for this. Since I've seen that go down very poorly many times in the past (who here remembers the ZendCon where they included Zend === PHP on their marketing materials?) I pushed the team towards saying PHP5 when referring to the implementation, and PHP when referring to the language syntax. That's not really a solution for us (PHP), but I do think the issue of separating the language from the implementation is useful, even if our (PHP) implementation of PHP (syntax) is and will always be the de-facto reference implementation. -Sara P.S. - Pronouns are getting hard, yo. Until we figure it out, I will be referring to the current common implementation as Zippy. Hopefully it catches on. Sounds like a Zend ImPlementation of PYthon... All I could think was in that case, who's Bungle? ;) -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] On voting, including the next release name.
The way voting works now, I happen to know which option is winning. I happened to know that *before* I cast my vote. The current results are posted on the RFC, and the same information percolated into emails encouraging folks to vote. I wonder, though, if knowing which was leading and who chose which side affected my vote (This is hardly an internals topic, and I'm hesitant to reply on this list, but…) FWIW, I think it's valuable to see what other people have voted. For example, if I'm looking over an RFC and see that my opinion is in opposition to someone else I respect in the community, it may cause me to reconsider. (e.g. if I noticed that I'd voted against Sara's vote, it would make me wonder what I missed). S
Re: [PHP-DEV] [RFC] imagettf* deprecation/removal
On Jul 27, 2014, at 1:19 PM, Pierre Joye pierre@gmail.com wrote: However the idea to add yet other warnings/notices to ext/gd is not something I like to see in GD. I will rather remove many for php-next instead of adding more. Also some new font APIs may as well make the whole ttf ones less relevant, see the upstream version. Pierre, I would only want to add E_DEPRECATED to the function calls if we are actually going to remove them. Otherwise, I agree that we should not add it. Also, I noted it in the RFC, but want to make mention here in case you did not see: I’m suggesting E_DEPRECATED in 5.6.z+1 and removal in php.next. On Jul 27, 2014, at 1:22 PM, Andrea Faulds a...@ajf.me wrote: The API signatures are compatible, yes? In which case, just make the legacy functions be aliases of the new ones. This avoids breaking everyone’s code. Andrea, I don’t think that assessment accurately reflects the situation. I’m suggesting to change the userland API in php.next. According to the release process the whole point of a php.next is to break the API for improvements. Anyone upgrading to php.next is going to have to check for BC breaks. I’m suggesting having this minor change be one of the BC breaks in php.next. I’m not making the argument that it is important from a purely technical POV; I don’t believe it is. I’m making the argument that it is important from an operational POV. Removing them prevents newcomers and gurus from ever having any question about which function to use.
Re: [PHP-DEV] [RFC] imagettf* deprecation/removal
On 27 Jul 2014, at 19:17, Lonny Kapelushnik lo...@lonnylot.com wrote: I’m suggesting having this minor change be one of the BC breaks in php.next. I’m not making the argument that it is important from a purely technical POV; I don’t believe it is. I’m making the argument that it is important from an operational POV. Removing them prevents newcomers and gurus from ever having any question about which function to use. Making them FALIASes also clears up any doubts. Either is equally valid. -- 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] imagettf* deprecation/removal
On Jul 27, 2014 8:17 PM, Lonny Kapelushnik lo...@lonnylot.com wrote: On Jul 27, 2014, at 1:19 PM, Pierre Joye pierre@gmail.com wrote: However the idea to add yet other warnings/notices to ext/gd is not something I like to see in GD. I will rather remove many for php-next instead of adding more. Also some new font APIs may as well make the whole ttf ones less relevant, see the upstream version. Pierre, I would only want to add E_DEPRECATED to the function calls if we are actually going to remove them. Hm. I do not think it is a good idea. As I said, I am really not willing to add more warnings for the sake of adding them. There is no difference in the implementation whether one uses these functions or the other. A note in the doc stating that should suffice. Or do you have an argument to still do it? What would the win? Otherwise, I agree that we should not add it. Also, I noted it in the RFC, but want to make mention here in case you did not see: I’m suggesting E_DEPRECATED in 5.6.z+1 and removal in php.next. On Jul 27, 2014, at 1:22 PM, Andrea Faulds a...@ajf.me wrote: The API signatures are compatible, yes? In which case, just make the legacy functions be aliases of the new ones. This avoids breaking everyone’s code. Andrea, I don’t think that assessment accurately reflects the situation. I’m suggesting to change the userland API in php.next. According to the release process the whole point of a php.next is to break the API for improvements. Anyone upgrading to php.next is going to have to check for BC breaks. I’m suggesting having this minor change be one of the BC breaks in php.next. I’m not making the argument that it is important from a purely technical POV; I don’t believe it is. I’m making the argument that it is important from an operational POV. Removing them prevents newcomers and gurus from ever having any question about which function to use.
Re: [PHP-DEV] [RFC] imagettf* deprecation/removal
On Sun, Jul 27, 2014 at 9:30 PM, Pierre Joye pierre@gmail.com wrote: On Jul 27, 2014 8:17 PM, Lonny Kapelushnik lo...@lonnylot.com wrote: On Jul 27, 2014, at 1:19 PM, Pierre Joye pierre@gmail.com wrote: However the idea to add yet other warnings/notices to ext/gd is not something I like to see in GD. I will rather remove many for php-next instead of adding more. Also some new font APIs may as well make the whole ttf ones less relevant, see the upstream version. Pierre, I would only want to add E_DEPRECATED to the function calls if we are actually going to remove them. Hm. I do not think it is a good idea. As I said, I am really not willing to add more warnings for the sake of adding them. There is no difference in the implementation whether one uses these functions or the other. A note in the doc stating that should suffice. Or do you have an argument to still do it? What would the win? If there are two functions doing essentially the same thing, we should remove one of them. In order to remove a function it must first be deprecated. The proposal sounds reasonable to me. There's no need to keep around legacy cruft through aliases. Nikita
Re: [PHP-DEV] RFC: Move phpng to master
Hi all, On Sun, Jul 27, 2014 at 5:03 PM, Michael Wallner mike.php@gmail.com wrote: On 27 Jul 2014 09:26, Kris Craig kris.cr...@gmail.com wrote: On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner mike.php@gmail.com wrote: On 27 Jul 2014 08:23, Kris Craig kris.cr...@gmail.com wrote: Here's my question to counter yours, Michael: What's the rush? Every day php-ng is not GA, PHP is losing ground to its competitors. Umm, how? Do you have any data to support this? According to http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing. As far as our competitors are concerned, well: http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python As you can see, PHP continues to dominate with over 80% market share and no signs-- at least, none that I can see-- that we are losing ground as you stated. Surely it's wise to make the same wrong assumptions Microsoft did with Internet Explorer? PHP is losing as a general scripting language for sure. JavaScript is winning in this area even if it was originated as a web client scripting language. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://langpop.com/ We are better to consider this situation seriously. IMHO. Focus on web as well as encourage general usage is what we need. Making PHP a choice for new project should be one of the most important objective. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [VOTE] RFC: Catchable call to a member function of a non-object
Hi Timm, On Sun, Jul 27, 2014 at 5:56 PM, Timm Friebe p...@thekid.de wrote: Only thing that I don't like is it depends on error message to be useful rather than error code/status. Was this discussed? Just curious. No, this wasn't discussed so far. You're right, this could make the code inside the error handler more readable and robust. It would mean, however, changing all the other E_RECOVERABLE_ERRORs too, like argument type mismatching and certain closure and generator operations; and thus was out of scope. I remember this from a couple of years back though; but can't recall why it was never done. Looking forward new RFC. We are better to have cleaner API. Optional parameter for user defined error handler is adequate, probably. Addition to error context is the cleanest, perhaps. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] RFC: Move phpng to master
On Sun, Jul 27, 2014 at 3:00 AM, Michael Wallner mike.php@gmail.com wrote: On 27 07 2014, at 11:44, Kris Craig kris.cr...@gmail.com wrote: [a lot] Maybe because you see those as competitors, You're the one who said PHP was losing ground to its competitors, not I. but I see HHVM and friends as current competitors, being evaluated to replace stock PHP, which is definitely not covered by any nice statistics you can currently view. So, in other words, you're basing your claim on anecdotal and purely hypothetical assumptions about unnamed people evaluating other languages to replace PHP. Even if your self-serving guess were true, for which there is no evidence that has been presented here, it still wouldn't substantiate your claim because evaluating alternatives to your current codebase doesn't mean you're going to actually switch to any of them. So either way, PHP is not, as you claimed, losing ground to anyone. [a lot] I've been trying to maintain a civil discussion here, but I have to say, Michael, thus far you have done nothing but make immature, snyde personal attacks and baseless, factually inaccurate claims. You have not contributed anything substantive or constructive to this debate up to this point. From your rolling eyes comment where you speculated about your dog wanting voting rights to now, you have been very disrespectful and uncivil toward everyone here. I don't want to discourage anyone from expressing their views, but on the same token, I'm not here to feed trolls. This issue clearly brings out strong emotions in some people and we clearly disagree on certain points. That said, please make a greater effort to be respectful toward other people on this list, whether you agree with them or not. Your trolling comments have all but hijacked this thread over the last 17 hours and it's detracting from substantive debate that needs to happen. If you have some issue with me personally, please take it off-list. If you're going to post further on this thread, please try to be more respectful and mature in your comments. --Kris http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js
Re: [PHP-DEV] RFC: Move phpng to master
On Sun, Jul 27, 2014 at 3:54 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Sun, Jul 27, 2014 at 5:03 PM, Michael Wallner mike.php@gmail.com wrote: On 27 Jul 2014 09:26, Kris Craig kris.cr...@gmail.com wrote: On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner mike.php@gmail.com wrote: On 27 Jul 2014 08:23, Kris Craig kris.cr...@gmail.com wrote: Here's my question to counter yours, Michael: What's the rush? Every day php-ng is not GA, PHP is losing ground to its competitors. Umm, how? Do you have any data to support this? According to http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing. As far as our competitors are concerned, well: http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python As you can see, PHP continues to dominate with over 80% market share and no signs-- at least, none that I can see-- that we are losing ground as you stated. Surely it's wise to make the same wrong assumptions Microsoft did with Internet Explorer? PHP is losing as a general scripting language for sure. JavaScript is winning in this area even if it was originated as a web client scripting language. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://langpop.com/ We are better to consider this situation seriously. IMHO. Focus on web as well as encourage general usage is what we need. Making PHP a choice for new project should be one of the most important objective. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net According to w3techs, JavaScript retains an extremely tiny market share in terms of general purpose languages: http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js It looks like the sources are all measuring different metrics. It would be interesting to see a closer analysis of the data and figure out which metrics are the most relevant to this question. --Kris
Re: [PHP-DEV] RFC: Move phpng to master
Hi Kris, On Mon, Jul 28, 2014 at 9:18 AM, Kris Craig kris.cr...@gmail.com wrote: According to w3techs, JavaScript retains an extremely tiny market share in terms of general purpose languages: http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js It looks like the sources are all measuring different metrics. It would be interesting to see a closer analysis of the data and figure out which metrics are the most relevant to this question. Since we have enough market share on web apps already, why don't we focus more on developers? There are many awesome none web app tools that are developed with JavaScript because of it's popularity and developers' passion. PHP is losing popularity for sure. http://www.tiobe.com/index.php/content/paperinfo/tpci/PHP.html PHP is the worst in terms of lost popularity among top 20 languages. It should be a flag for us to adjust our strategy/view. Market share comes after language popularity. When market share has changed, it would be too late. Anyway, I'm willing to have phpng as master, as well as INT64 branch. Both are good for PHP. IMO. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] RFC: Move phpng to master
First off, I realize I am top posting but this thread is becoming extremely off-topic, unbalanced and overall ridiculous to see from the sidelines as someone that contributes to open source and also utilizes PHP on a daily basis for more than the last decade. Seriously, cut the shit! Everyone is bringing this to a personal and completely insane area; let's focus on the facts not the reactions wherever they might come from. Work together, no one ever agrees 100% of the time and continuing on that note, no one makes the best choices 100% of the time. Surely, as a community we will not always agree on implementations, timing and what is done in secret vs. not, what is more maintainable vs. what is not. Where to dedicate focus etc. Open source projects often have this issue. Also, no I am not taking a stance or side on what is best for the language. People contributing to the engine are much smarter than I in this level and the right choice I am certain will prevail. But have a reasonable conversations on facts vs. personal opinions and vendettas. Now, PHP is a balanced language; performance comes with a cost if it be memory, CPU spikes, maintainability, readability, etc. We all program here; this is always a trade off we need to determine, analyze and identify. These things have to be taken into account. Documentation is nice but not always necessary. Depending on what it will change and how much affect it will have on say extension developers and existing people contributing to core has to be taken into account. Let's get our heads straight, determine our focus for the next few years and start to move forward. Sure other languages gain and lose on PHP but this will always be the case and should not be the core focus; we're not a company that's on the stock market. Languages will evolve, change, become invented but it's not like PHP is going away in a rapid decline; sure there is more languages and more competition out there. For instance, I have been writing node.js lately and find a massive benefit in certain types of projects; it comes to utilizing the right tool for the right job. Surely you are not going to attempt to write PHP for something that should be done in assembly or visa-versa. Market share does affect our jobs and careers but there is a reason the language has been successful and will continue to be. A speed increase is not a magical bullet here, if that was the case and they wanted to use PHP they'd use HHVM or even Hack lang and change their usage. (Yes, there are other things there but come on, 99% of the time core PHP speed is not the issue.) Let's save the effort on this useless conversation, focus on driving SOMETHING forward, WHATEVER that may be and stop taking everything so damn personal. Regards, Mike On Sun, Jul 27, 2014 at 7:18 PM, Kris Craig kris.cr...@gmail.com wrote: On Sun, Jul 27, 2014 at 3:54 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi all, On Sun, Jul 27, 2014 at 5:03 PM, Michael Wallner mike.php@gmail.com wrote: On 27 Jul 2014 09:26, Kris Craig kris.cr...@gmail.com wrote: On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner mike.php@gmail.com wrote: On 27 Jul 2014 08:23, Kris Craig kris.cr...@gmail.com wrote: Here's my question to counter yours, Michael: What's the rush? Every day php-ng is not GA, PHP is losing ground to its competitors. Umm, how? Do you have any data to support this? According to http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing. As far as our competitors are concerned, well: http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python As you can see, PHP continues to dominate with over 80% market share and no signs-- at least, none that I can see-- that we are losing ground as you stated. Surely it's wise to make the same wrong assumptions Microsoft did with Internet Explorer? PHP is losing as a general scripting language for sure. JavaScript is winning in this area even if it was originated as a web client scripting language. http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html http://langpop.com/ We are better to consider this situation seriously. IMHO. Focus on web as well as encourage general usage is what we need. Making PHP a choice for new project should be one of the most important objective. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net According to w3techs, JavaScript retains an extremely tiny market share in terms of general purpose languages: http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js It looks like the sources are all measuring different metrics. It would be interesting to see a closer analysis of the data and figure out which metrics are the most relevant to this question. --Kris
[PHP-DEV] Re： [PHP-DEV] RFC: Move phpng to master
On 27 07 2014, at 11:44, Kris Craig kris.cr...@gmail.com (mailto:kris.cr...@gmail.com) wrote: [a lot] Maybe because you see those as competitors, but I see HHVM and friends as current competitors, being evaluated to replace stock PHP, which is definitely not covered by any nice statistics you can currently view. I can confirm that, wikimedia is migrating from PHP to HHVM, see: http://lists.wikimedia.org/pipermail/wikitech-l/2014-July/077690.html and I also have saw many friends talking about migrating from PHP to HHVM only for performance gain. Cheers, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Cheers, David Dai
[PHP-DEV] PHP namespace?
Hi all,
Since we have discussion for Next PHP, PHP namespace discussion would be
nice
to have.
Currently, PHP module functions/classes/interfaces are using global(root)
namespace.
If it is changed to use its own namespace, user space APIs may be changed
flexible and user controlled manner. Thus, PHP may have
- Consistent naming
- Consistent parameter order
- Graceful function/class/interface deprecation
(We know what we should do for these, right?)
without much compatibility issues.
PHP namespace may be used to provide PHP(and 3rd party)
functions/classes/interfaces/constants.
PHP\Legacy (or whatever) may be used for legacy
functions/classes/interfaces/constants.
From PHP 5.6, userland function aliasing can be done with namespace.
Following code overrides existing function.
?php
use function \mb_strlen as strlen;
var_dump(strlen('日本語'));
?
Result:
int(3)
It's good to use prefered API, but it requires use for every function
APIs to be overridden.
Note: Classes/Interfaces may override by use one by one also.
With PHP and PHP\Legacy namespace, user may write:
?php
namespace PHP; // Use current PHP functions/classes/interfaces/constants
// Code uses current API
?
?php
namespace PHP;
namespace PHP\Legacy; // Override with legacy PHP
functions/classes/interfaces/constants.
// Code uses legacy API
?
For compatibility, default namespace setting would be nice to have.
- None for compiled default
- PHP for php.ini-*
Previous example codes became:
?php
// Code uses current API
?
?php
namespace PHP\Legacy; // Override with legacy PHP
functions/classes/interfaces/constants.
// Code uses legacy API
?
Issue would be codes that assume PHP functions/classes/interfaces/constants
are
defined in global(root) namespace. (e.g. \strlen()) This could be
workaround by allowing
use aliasing to global(root) namespace. (e.g. use PHP\Legacy as \;) In
this case,
current functions/classes/interfaces may stay in global(root) namespace.
(or use PHP as \;)
Programmers may shoot their own foot by this. This is the trade off of
flexibility.
Any thoughts and/or comments?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
