[PHP-DEV] About PHP NG "document lacking" argument
Hey: First of all, I don't want to make *that* thead longer... as you can see, some devers says critically phpng is lacking of document, and they make that as the main reason for them to against phpng. I have to say, in my opinion it's totally ridiculous. 1. how many devers in here really knows zend engine? how many tried to know it? I assume a little, as you can see, only a few activate zend engine maintainers now. dmitry is the most experience one. 2. does PHP really has had a good API document? no, when I first tried to write a extension, I found no documents, or they was far beyond outdate, I event don't know how config.m4 works.. I learn PHP by reading the codes, and the example under ext/* 3. is document really important for PHPng? I don't think so, PHP can always read the codes, PHP is opensource , it is not *MS* who need document to tell people what it did in dark. 4. is PHPng API became more ugly? or harder to maintainable? I feel really bad to see somebody said such things... first of all. ugly, maintainable. it is too too subjective, and to be honest, it's obviously biased attitude. second, I , the main author of PHPNG, and Nikita, Dmitry, are the most activate internal contributors now. so you are saying we are writing ugly codes? I really can not agree with that. actually, the zend_hash API become more clear, and beatifuy than before. maintainable? who is the main force to maintain the PHP internal now? yes, the authors of PHPNG.. I think I have the more rights to say whether it is more maintainer able or not. and it's become more maintainable, because of more clean API and more reasonable logics. 5. are we going to write docs? yes, for people, who in love with PHP, who want to make PHP extensions, we are glad to write some APIs (which will be enough in a dever eye). actually we already doing it: https://wiki.php.net/phpng-upgrading 6. is PHPng really faster? yes, from my own test, it get more than 80% qps improvement in wordpress than php-5.6 . for those big PHP users, that means they can save lots of money. I see no reason to not have such a great change. anyone who tried to block such a amazing feature merge into PHP, is doing crime for PHP. I am not a native english speaker, so maybe I confused you in some words , sorry for that. I really hope the people in this group, the people who loves PHP, the people who want PHP become more popular here. stop less reasonable arguing, let's together to make this biggest change merge into PHP, make PHP users more easy life.. If you think we need write doc, let us write it. If you think we need more clean APIs? please tell me what style is more clean, we can disccuss it, refactor it. If you meet problems when you try to upgrade you extension from PHP to PHPng, let's add more info into the doc, or I can do some part of your work for you. as I have almost refactor all the extensions under ext/ and what do you want else? please, just, please, stop the worthless talking, I really don't want to see such useless words anymore.. thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.4.31 Released
Hello! The PHP development team announces the immediate availability of PHP 5.4.31. Over 10 bugs were fixed in this release. All users of PHP 5.4 are encouraged to upgrade to this release. For source downloads of PHP 5.4.31 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/ The list of changes are recorded in the ChangeLog: http://www.php.net/ChangeLog-5.php#5.4.31 Stanislav Malyshev PHP 5.4 RM -- 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 Fri, Jul 25, 2014 at 6:28 AM, Kris Craig wrote: >> While this is a major change to the language implementation, it does not > actually affect end users in any meaningful way except for the positive > ‘side effect’ of their apps running faster. So while we believe that > technically a 50%+1 vote should suffice, we hope to get well over 2/3. 2/3 is required, there is no doubt about it. That being said, I think we should block this RFC as it is by far one of the poorest one from a content point of view (referring to the RFC itself here). phpng is a huge change, or better said a huge set of huge changes. Even the php-next version number RFC has more details that this one. This is disturbing. The various document should be linked or merged (docs relevant directly to this rfc should be merged, link to https://wiki.php.net/phpng-upgrading is missing too. I can help with these steps next week. 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: Move phpng to master
On Thu, Jul 24, 2014 at 8:47 PM, Yasuo Ohgaki wrote: > Hi Zeev, > > On Mon, Jul 21, 2014 at 4:31 PM, Zeev Suraski wrote: > > > The RFC is available at https://wiki.php.net/rfc/phpng > > > > > > > > Some supporting links available down below. > > > > > > > > Comments welcome! > > > > While this is a major change to the language implementation, it does not actually affect end users in any meaningful way except for the positive ‘side effect’ of their apps running faster. So while we believe that technically a 50%+1 vote should suffice, we hope to get well over 2/3. If you're not going to delay this, then you should at very least clarify the wording in this section. You believe 50%+1 should suffice but hope to get well over 2/3. So is the *required* majority 50%+1 or 2/3? I should also point out that, according to the Voting RFC, whether or not an RFC "actually affects end users in any meaningful way" is NOT a factor in determining whether a 2/3 supermajority is required or not. Here's what it actually states: > For these reasons, a feature affecting the language itself (new syntax for example) will be considered as 'accepted' if it wins a 2/3 of the votes. Other RFCs require 50% + 1 votes to get 'accepted'. Since the phpng RFC already acknowledges that it affects the language itself, this is clearly a 2/3 requirement situation. Whether it affects end-users or not is irrelevant. Under current rules, your RFC must have 2/3 support in order to pass. As such, I ask that you at least update the wording to make it clear that 2/3 *is* required for the RFC to pass in order to avoid confusion when it comes to a vote. I still think you should hold-off until these other issues of dispute are resolved, though. But that's your choice. I simply ask that you fix the required majority section to make it in compliance with current voting rules. --Kris
Re: [PHP-DEV] RFC: Move phpng to master
Hi Zeev, On Mon, Jul 21, 2014 at 4:31 PM, Zeev Suraski wrote: > The RFC is available at https://wiki.php.net/rfc/phpng > > > > Some supporting links available down below. > > > > Comments welcome! > It says Zend2 in zend.h 25 #define ZEND_VERSION "2.7.0-dev" 26 27 #define ZEND_ENGINE_2 Isn't it better named Zend3? It may be changed anytime, though. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] RFC: Move phpng to master
On Fri, Jul 25, 2014 at 12:51 AM, Zeev Suraski wrote: > That said, I completely disagree with the "delayers", who also happen > to be ones who have a repeated tendency to talk a lot more than they > do. Dmitry is one if the biggest php.net doers - and us can > understand how it runs him the wrong way. Excuse me? As one of the "delayers", we do a shit load of work and I was one of the 1st to contribute to phpng, code and doc, before giving up because of the constant moving and lack of sync possibility. I never said that Dmitry does nothing or bad work. But rushing this RFC, even if you may get it accepted, is a strategic mistake. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On 24 Jul 2014, at 09:42, Patrick Schaaf wrote: > How does the proposal affect method compatibility between subclasses and > baseclasses? Will two methods there, differing in the scalar type annotations > of one of their arguments, elicit STRICT warnings, like object type > annotations do? As implemented, yes. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On 13 Jul 2014, at 02:57, Andrea Faulds wrote:
> The RFC is here: https://wiki.php.net/rfc/scalar_type_hinting_with_cast
>
> A pull request is here: https://github.com/php/php-src/pull/717
I just updated the patch and RFC to include overflow safety for the integer
type hint. This means that the following code is an error:
function foo(int $a) {}
foo(‘8493284029384029384028409304249230894’);
This is actually a level of safety you couldn’t get with any other proposal. If
you explicitly cast with (int) it will silently saturate/cap the integer (data
is lost), and zend_parse_parameters will silently saturate or truncate
(depending on the function).
This is consistent with passing a float. Were I to do the following, it was
already an error in the proposal:
function foo(int $a) {}
foo(8493284029384029384028409304249230894.0);
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On 23 Jul 2014, at 19:37, Andrea Faulds wrote: > > On 23 Jul 2014, at 19:21, Robert Williams wrote: > >> Also, do int, float, and numeric accept numbers in octal, hex, scientific >> notation, etc.? I don’t believe there are any examples in the RFC that >> intentionally or accidentally show what happens with, say, 0x2f as a value. > > Ooh, you’ve caught me out there. The patch as it stands would permit such > non-decimal numbers, which isn’t what it should do as > convert_to_long_base_safe should actually permit only the specified base. > > So, yes it does permit non-decimal numbers, but it’s a bug I need to fix. Said bug has been fixed in the proposed patch now. “0xa” is no longer valid for int, float or numeric. It never should’ve been valid, but the implementation of convert_to_(long_base|double|numeric)_safe was incorrect. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 final release
On Fri, Jul 25, 2014 at 12:23 AM, George Wang wrote: > > On 7/24/2014 10:40 AM, Johannes Schlüter wrote: > >> On Wed, 2014-07-23 at 18:22 -0400, George Wang wrote: >> >>> Hi, >>> >>> I have a request to include our latest sapi/litespeed V6.6 to the EOL >>> PHP 5.3 release. I thought it was EOL already. >>> >> PHP 5.3 is in extended support and only receives security related fixes. >> In general people should use newer versions which have more bug fixes >> and are faster. >> I don't think these updates qualify. >> >> We had some difficult to commit our LiteSpeed SAPI code into PHP >>> source repository before, so it is lagging behind our office release. >>> >> What kind of issues? >> > A while back, I can only push change to master branch, but cannot push to > other branches. > So, master was updated to V6.4 last year, but other branches still stay at > V5.5, which was released 4 years ago. > > I can push changes to other branches without problem now, all up2date now > except the 5.3 branch. > > Best regards, > George > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > as I mentioned previously when you reported the issue, based on the push reject message, you were trying to push to a subdirectory, where you didn't have access (probably had something not merged upwards in Zend/ or similar). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] RFC: Move phpng to master
Hi Dmitry, On 25 Jul, 2014, at 6:09 am, Dmitry Stogov wrote: > any one may vote according to their thoughts > I'm not going to persuade any one. > I already know the opinion of the majority. > > Unfortunately, now many people lessen to the guys who speaks a lot. > I was never able to do it :), but ... look into results we provide. > They are more expressive than any words. First of all, kudos for all the hard you and the team have been putting into this :) From a developer’s point of view it would be nice to see a write-up of some of the changes that were made to the API's; I’m currently aware of the array (hash) API changes which are definitely an improvement over the old one, but there may be more that could also use an “idiom conversion guide”. > > Thanks. Dmitry, > > > > > > > > > On Fri, Jul 25, 2014 at 1:39 AM, Kris Craig wrote: > >> >> >> >> On Thu, Jul 24, 2014 at 1:37 PM, Dmitry Stogov wrote: >> >>> one week - two weeks - months - years. >>> I'll wait. >>> I know what I'm doing. I'll make it. >>> >>> Dmitry. >>> >>> >>> On Fri, Jul 25, 2014 at 12:26 AM, Pierre Joye >>> wrote: >>> On Jul 24, 2014 10:13 PM, "Dmitry Stogov" wrote: > > agree, > > I just don't see any blockers, except for Pierre. Come on Dmitry, I am not the only who has asked that. >>> >> >> Just to throw in my usual two-cents, it seems to me that this RFC is very >> premature. It's the same sort of over-eagerness I saw in the front-page >> news post a few weeks back. I understand what you guys are trying to >> accomplish and I applaud you for it, but as far as I can see, it's still >> quite a ways away from being ready for prime time. And yet, you seem to be >> acting like it's already there. >> >> Aside from the code needing to be ready/tested, you also need to have a >> more matured collaboration with community folks outside your project like >> Pierre, which at the moment appears to be downright hostile. Even if the >> code looked great and everything else was in place, I would never vote to >> switch over to such a drastic new schema when there's this much animosity >> and controversy surrounding it. I keep reading complaints about questions >> being ignored and conflicting stories about secrecy and process. I also >> think there's some merit to the concern raised about the ambiguity being a >> prelude to patches being rejected over trivial concerns. >> >> I think you guys need to slow down and mend a few fences if you want to >> make this happen. As much as I like the goals of this project, I'm forced >> to vote -1 for now, as well. I just think you're jumping the gun when >> there are too many unanswered questions/concerns still out there. >> >> --Kris >> >> Best, Tjerk -- 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 25 ביול 2014, at 01:35, Jan Ehrhardt wrote: > > Dmitry Stogov in php.internals (Fri, 25 Jul 2014 02:09:53 +0400): >> I already know the opinion of the majority. > > Do you also know the opinion of 2/3 of the voters? Guys, Let's deescalate here. Dmitry is understandably quite emotionally attached to this. I probably wouldn't have sent the emails he sent tonight on this thread had I been him - but I'm not... I agree with Nikita - there's no reason to shorten the mandatory 2wk cycle and I'd reply with no had others not beat me to it. I'd be highly annoyed if it was done to me on an RFC I care about. That said, I completely disagree with the "delayers", who also happen to be ones who have a repeated tendency to talk a lot more than they do. Dmitry is one if the biggest php.net doers - and us can understand how it runs him the wrong way. The main missing piece was docs, and we made some progress there - but probably need some more time for people to provide feedback and adjust. Other than that I see absolutely no reason to stall beyond the 2wk discussion period, and every reason to floor the has pedal. I don't know what the voting outcome would be, but as I wrote in the RFC - I hope it will be well above 2/3, so that we have an awesome engine to match the shiny new version number :) Zeev -- 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 Thu, Jul 24, 2014 at 3:39 PM, Zeev Suraski wrote: > > On 25 ביול 2014, at 01:35, Jan Ehrhardt wrote: > > > > Dmitry Stogov in php.internals (Fri, 25 Jul 2014 02:09:53 +0400): > >> I already know the opinion of the majority. > > > > Do you also know the opinion of 2/3 of the voters? > > Guys, > > Let's deescalate here. Dmitry is understandably quite attached to this Very much agreed! I'd love to see cooler heads prevail on this. I see no reason why both sides can't come together on this if they'd just drop all this posturing. Supporters should slow down and take the time to answer questions and build consensus. Critics should remember that these guys have put a lot of work into it and are understandably eager to see it come to fruition. I think that would make this a much more constructive, much less melodramatic process. And I'd certainly be inclined to vote in favor of it once it's no longer a matter of heated controversy. =) --Kris
Re: [PHP-DEV] RFC: Move phpng to master
> On 25 ביול 2014, at 01:35, Jan Ehrhardt wrote: > > Dmitry Stogov in php.internals (Fri, 25 Jul 2014 02:09:53 +0400): >> I already know the opinion of the majority. > > Do you also know the opinion of 2/3 of the voters? Guys, Let's deescalate here. Dmitry is understandably quite attached to this -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
Dmitry Stogov in php.internals (Fri, 25 Jul 2014 02:09:53 +0400): >I already know the opinion of the majority. Do you also know the opinion of 2/3 of the voters? Jan (without voting right BTW) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 final release
On 7/24/2014 10:40 AM, Johannes Schlüter wrote: On Wed, 2014-07-23 at 18:22 -0400, George Wang wrote: Hi, I have a request to include our latest sapi/litespeed V6.6 to the EOL PHP 5.3 release. I thought it was EOL already. PHP 5.3 is in extended support and only receives security related fixes. In general people should use newer versions which have more bug fixes and are faster. I don't think these updates qualify. We had some difficult to commit our LiteSpeed SAPI code into PHP source repository before, so it is lagging behind our office release. What kind of issues? A while back, I can only push change to master branch, but cannot push to other branches. So, master was updated to V6.4 last year, but other branches still stay at V5.5, which was released 4 years ago. I can push changes to other branches without problem now, all up2date now except the 5.3 branch. Best regards, George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
any one may vote according to their thoughts I'm not going to persuade any one. I already know the opinion of the majority. Unfortunately, now many people lessen to the guys who speaks a lot. I was never able to do it :), but ... look into results we provide. They are more expressive than any words. Thanks. Dmitry, On Fri, Jul 25, 2014 at 1:39 AM, Kris Craig wrote: > > > > On Thu, Jul 24, 2014 at 1:37 PM, Dmitry Stogov wrote: > >> one week - two weeks - months - years. >> I'll wait. >> I know what I'm doing. I'll make it. >> >> Dmitry. >> >> >> On Fri, Jul 25, 2014 at 12:26 AM, Pierre Joye >> wrote: >> >> > >> > On Jul 24, 2014 10:13 PM, "Dmitry Stogov" wrote: >> > > >> > > agree, >> > > >> > > I just don't see any blockers, except for Pierre. >> > >> > Come on Dmitry, I am not the only who has asked that. >> > >> > > Just to throw in my usual two-cents, it seems to me that this RFC is very > premature. It's the same sort of over-eagerness I saw in the front-page > news post a few weeks back. I understand what you guys are trying to > accomplish and I applaud you for it, but as far as I can see, it's still > quite a ways away from being ready for prime time. And yet, you seem to be > acting like it's already there. > > Aside from the code needing to be ready/tested, you also need to have a > more matured collaboration with community folks outside your project like > Pierre, which at the moment appears to be downright hostile. Even if the > code looked great and everything else was in place, I would never vote to > switch over to such a drastic new schema when there's this much animosity > and controversy surrounding it. I keep reading complaints about questions > being ignored and conflicting stories about secrecy and process. I also > think there's some merit to the concern raised about the ambiguity being a > prelude to patches being rejected over trivial concerns. > > I think you guys need to slow down and mend a few fences if you want to > make this happen. As much as I like the goals of this project, I'm forced > to vote -1 for now, as well. I just think you're jumping the gun when > there are too many unanswered questions/concerns still out there. > > --Kris > >
Re: [PHP-DEV] RFC: Move phpng to master
On Thu, Jul 24, 2014 at 1:37 PM, Dmitry Stogov wrote: > one week - two weeks - months - years. > I'll wait. > I know what I'm doing. I'll make it. > > Dmitry. > > > On Fri, Jul 25, 2014 at 12:26 AM, Pierre Joye > wrote: > > > > > On Jul 24, 2014 10:13 PM, "Dmitry Stogov" wrote: > > > > > > agree, > > > > > > I just don't see any blockers, except for Pierre. > > > > Come on Dmitry, I am not the only who has asked that. > > > Just to throw in my usual two-cents, it seems to me that this RFC is very premature. It's the same sort of over-eagerness I saw in the front-page news post a few weeks back. I understand what you guys are trying to accomplish and I applaud you for it, but as far as I can see, it's still quite a ways away from being ready for prime time. And yet, you seem to be acting like it's already there. Aside from the code needing to be ready/tested, you also need to have a more matured collaboration with community folks outside your project like Pierre, which at the moment appears to be downright hostile. Even if the code looked great and everything else was in place, I would never vote to switch over to such a drastic new schema when there's this much animosity and controversy surrounding it. I keep reading complaints about questions being ignored and conflicting stories about secrecy and process. I also think there's some merit to the concern raised about the ambiguity being a prelude to patches being rejected over trivial concerns. I think you guys need to slow down and mend a few fences if you want to make this happen. As much as I like the goals of this project, I'm forced to vote -1 for now, as well. I just think you're jumping the gun when there are too many unanswered questions/concerns still out there. --Kris
Re: [PHP-DEV] Re: Using stada...@lists.php.net for spec work
On Thu, Jul 24, 2014 at 1:57 PM, Zeev Suraski wrote: > standards-subscr...@lists.php.net I believe, not the other way around > You are correct, sir. Thank you. And bjori beat me to it on adding it to web-php: https://github.com/php/web-php/commit/136f8f13631420e50055b0f8bd4737fbadc1f982 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Using stada...@lists.php.net for spec work
standards-subscr...@lists.php.net I believe, not the other way around > -Original Message- > From: p...@golemon.com [mailto:p...@golemon.com] On Behalf Of Sara > Golemon > Sent: Thursday, July 24, 2014 11:54 PM > To: James Gilliland > Cc: PHP Internals > Subject: Re: [PHP-DEV] Re: Using stada...@lists.php.net for spec work > > On Thu, Jul 24, 2014 at 1:51 PM, James Gilliland > wrote: > > Might I then suggest someone update http://php.net/mailing-lists.php? > > > Yeah, I can push that. Though fwiw, emailing > subscribe-standa...@lists.php.net > seems to be more reliable than the webform. > > -Sara > > -- > PHP Internals - PHP Runtime Development Mailing List To unsubscribe, > visit: > http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Using stada...@lists.php.net for spec work
Could be. Other then the webform though, I think that's the only place we document where things are happening. On Thu, Jul 24, 2014 at 3:54 PM, Sara Golemon wrote: > On Thu, Jul 24, 2014 at 1:51 PM, James Gilliland > wrote: > > Might I then suggest someone update http://php.net/mailing-lists.php? > > > Yeah, I can push that. Though fwiw, emailing > subscribe-standa...@lists.php.net seems to be more reliable than the > webform. > > -Sara >
RE: [PHP-DEV] PHP Language Specification
> -Original Message- > From: Andrea Faulds [mailto:a...@ajf.me] > Sent: Thursday, July 24, 2014 11:51 PM > To: Zeev Suraski > Cc: PHP internals > Subject: Re: [PHP-DEV] PHP Language Specification > > > I'd contend CPHP hasn't been named for 15 years as it has had no name for the > implementation itself. I have no idea what CPHP is, but we've had PHP named for the last 15+ years, and other implementations of it (like Quercus, Phalanger, etc. and now hhvm). Nothing changed today. Either way I'm going to end my participation in this part of the thread here. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Using stada...@lists.php.net for spec work
On Thu, Jul 24, 2014 at 1:51 PM, James Gilliland wrote: > Might I then suggest someone update http://php.net/mailing-lists.php? > Yeah, I can push that. Though fwiw, emailing subscribe-standa...@lists.php.net seems to be more reliable than the webform. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Using stada...@lists.php.net for spec work
Might I then suggest someone update http://php.net/mailing-lists.php? On Thu, Jul 24, 2014 at 3:38 PM, Sara Golemon wrote: > On Thu, Jul 24, 2014 at 11:24 AM, Stas Malyshev > wrote: > > I would like to propose to use list standa...@lists.php.net (which has > > been dormant since 2009) for PHP spec work. What do you think? > > > I'mma go ahead and make a command decision and just move discussion > there. (if it works out poorly, we can always move the topic back). > > To that end: http://news.php.net/php.standards/104 > > -Sara > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] PHP Language Specification
On 24 Jul 2014, at 21:47, Zeev Suraski wrote: > We saw how much time it took us to decide about a version number, let's > not waste cycles on coming up for a name for something that has been named > for over 15 years. I’d contend CPHP hasn’t been named for 15 years as it has had no name for the implementation itself. Regardless, I’m going to start using CPHP myself and hope it catches on. Though short of adopting a name for the implementation officially (even if it’s just a “nickname”), this problem will continue to exist, and people will keep having to add contract-style definitions to the start of documents explaining what the term they’ve invented to refer to the original implementation means. -- 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
> -Original Message- > From: Andrea Faulds [mailto:a...@ajf.me] > Sent: Thursday, July 24, 2014 11:44 PM > To: Zeev Suraski > Cc: Sara Golemon; Rowan Collins; PHP internals > Subject: Re: [PHP-DEV] PHP Language Specification > > > "PHP.net PHP" isn't the nicest of names. I think CPHP, analogous to CPython is > maybe the best of the available options. If it's for internal discussion purposes, it doesn't matter if it's the nicest of names. php.net PHP is an accurate description and there's no reason to create a new 'brand' here. We saw how much time it took us to decide about a version number, let's not waste cycles on coming up for a name for something that has been named for over 15 years. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Language Specification
On 24 Jul 2014, at 21:32, Zeev Suraski wrote: > Ok, maybe I missed the context, and if I did apologies for that. Are you > talking about a standard way of discussing it on internals@ when we talk > about the spec and different implementations of it? Yeah, sorry if I didn’t make myself clear. There are various unofficial internal names for the original PHP implementation including “Zend PHP”, and I think we should settle on one for internal use. We can have it be the “nickname”, much like CPython is the nickname of the original Python implementation. > In that case, my vote (in the risk of agreeing with someone I almost never > agree with) would be calling it 'php.net PHP', as that's exactly what it > is. php.net is not just the website but all of the php.net > infrastructure, the codebase, bug tracking system, etc. - seems like the > most accurate name for it. “PHP.net PHP” isn’t the nicest of names. I think CPHP, analogous to CPython is maybe the best of the available options. -- 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 Thu, Jul 24, 2014 at 10:26 PM, Andrea Faulds wrote: > > On 24 Jul 2014, at 21:23, Zeev Suraski wrote: > > > CPython is the name of the implementation, but python.org offers you to > > download Python, not CPython. CPython is an internal name kind of like > > php-src (more or less). In fact, as an average end user, you'd not know > > about CPython at all. > > Of course. So far as users care, CPython is Python. So far as users care, > Zend PHP/ZPHP/CPHP/php-src/vanilla PHP/whatever is PHP. > > However, from an internals perspective, we need to be able to distinguish > the two and this becomes particularly important now due to HHVM and the > specification. > > So, we should decide on a name for the original PHP implementation. > -- > Andrea Faulds > http://ajf.me/ > > I still think that Python/CPython is a good example, it shows how confusing can it be when the reference implementation and the language has a different name: http://stackoverflow.com/questions/17130975/python-vs-cpython As Zeev mentioned the CPython name is mostly just used for to refer to the vanilla implementation when comparing to others, but the codebase of it still refer to itself as python. I think the only case when you can have a separate name for the reference implementation than the name of the language is at the start, if you do it anytime later, it will cause some headaches, but it isn't impossible as we can see from the python example. Ruby is also an interesting example, there are also a bunch of alternative implementations, the reference implementation refers to itself as ruby, and when comparing it to other implementations it is either called MRI (Matz's Ruby Interpreter) or CRuby. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] PHP Language Specification
On 24/07/2014 21:28, Zeev Suraski wrote: "PHP 5.6" -> the php.net implementation This is the one that led us down this particular path: the spec will necessarily have versions of its own, and the obvious thing to do is to make them match the minor versions of the reference implementation; so "PHP 5.6" could mean "a php.net 5.6.x release" or the language specification matching that. To be honest, one of the things I was thinking about was the fact that the "Implementations" line on this Wikipedia template has no entry for the default implementation: https://en.wikipedia.org/wiki/Template:PHP Which is definitely too trivial to spend much energy debating. -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Using stada...@lists.php.net for spec work
On Thu, Jul 24, 2014 at 11:24 AM, Stas Malyshev wrote: > I would like to propose to use list standa...@lists.php.net (which has > been dormant since 2009) for PHP spec work. What do you think? > I'mma go ahead and make a command decision and just move discussion there. (if it works out poorly, we can always move the topic back). To that end: http://news.php.net/php.standards/104 -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
one week - two weeks - months - years. I'll wait. I know what I'm doing. I'll make it. Dmitry. On Fri, Jul 25, 2014 at 12:26 AM, Pierre Joye wrote: > > On Jul 24, 2014 10:13 PM, "Dmitry Stogov" wrote: > > > > agree, > > > > I just don't see any blockers, except for Pierre. > > Come on Dmitry, I am not the only who has asked that. >
RE: [PHP-DEV] PHP Language Specification
Maybe there’s hope for the middle east J *From:* Pierre Joye [mailto:pierre@gmail.com] *Sent:* Thursday, July 24, 2014 11:29 PM *To:* Zeev Suraski *Cc:* Andrea Faulds; PHP internals; Rowan Collins *Subject:* RE: [PHP-DEV] PHP Language Specification On Jul 24, 2014 10:02 PM, "Zeev Suraski" wrote: > > I think we're overcomplicating things a bit... > ... > absolutely refer to that thing you download from www.php.net (or packages > based off of it) - not the language spec. I totally agree with you here. PHP is and remains php.net's PHP. Cheers, Pierre
RE: [PHP-DEV] PHP Language Specification
> -Original Message- > From: Andrea Faulds [mailto:a...@ajf.me] > Sent: Thursday, July 24, 2014 11:26 PM > To: Zeev Suraski > Cc: Sara Golemon; Rowan Collins; PHP internals > Subject: Re: [PHP-DEV] PHP Language Specification > > > On 24 Jul 2014, at 21:23, Zeev Suraski wrote: > > However, from an internals perspective, we need to be able to distinguish the > two and this becomes particularly important now due to HHVM and the > specification. > > So, we should decide on a name for the original PHP implementation. Ok, maybe I missed the context, and if I did apologies for that. Are you talking about a standard way of discussing it on internals@ when we talk about the spec and different implementations of it? In that case, my vote (in the risk of agreeing with someone I almost never agree with) would be calling it 'php.net PHP', as that's exactly what it is. php.net is not just the website but all of the php.net infrastructure, the codebase, bug tracking system, etc. - seems like the most accurate name for it. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Language Specification
On 24/07/2014 21:12, Zeev Suraski wrote: I don't recall if it was === or 'is', but regardless, the meaning was absolutely 'Zend is PHP' (as in everything Zend does is PHP), and not 'PHP is Zend'. Regardless, since it was clearly misunderstood by many people we stopped using it :) See also the German national anthem, in which "Deutschland ueber alles" was intended to mean "consider German unification above your local power", not "Germany should rule the world", although it's no stretch to assume that Hitler favoured the latter interpretation. The current anthem consists only of the less easily reinterpreted third verse. Damn, Godwin's Law, sorry all! :( -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP Language Specification
On Jul 24, 2014 10:02 PM, "Zeev Suraski" wrote: > > I think we're overcomplicating things a bit... > ... > absolutely refer to that thing you download from www.php.net (or packages > based off of it) - not the language spec. I totally agree with you here. PHP is and remains php.net's PHP. Cheers, Pierre
RE: [PHP-DEV] PHP Language Specification
> -Original Message- > From: Andrea Faulds [mailto:a...@ajf.me] > Sent: Thursday, July 24, 2014 11:21 PM > To: Zeev Suraski > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] PHP Language Specification > > > On 24 Jul 2014, at 21:18, Zeev Suraski wrote: > > > No, there's no ambiguity at all - 'PHP' is the implementation, as it > > always has been. 'PHP language specification' or 'PHP spec' for short > > is the specification. Absolutely no ambiguity. > > So PHP is variously the language (as in PHP language specification) and an > implementation (as in PHP). Not at all. 'PHP' is the implementation, what you download off of php.net. 'PHP language specification' is the specification. That's exactly what I wrote before so I'm not sure it'll be clearer now, but I fail to see what's hard to understand about it :) > > Well, one reason is that it would be a horrible, horrible name > > (imagine us "Happy to announce php-src 5.6!", come on). But another > > is there's really absolutely no reason to change the name of PHP to > > anything at all. There would be the PHP spec, and there would be PHP. > > What does PHP mean here? The language? The vanilla implementation? PHP along depends on the context. We're humans, and we use the same words to mean different things in different context. "Download PHP" -> download the php.net implementation "PHP 5.6" -> the php.net implementation "PHP spec" -> the PHP "The PHP ecosystem" -> everything that has anything to do with PHP "A PHP developer" -> someone who can develop in PHP It's really not complicated, let's not pretend it is. Zeev -- 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 Jul 24, 2014 10:13 PM, "Dmitry Stogov" wrote: > > agree, > > I just don't see any blockers, except for Pierre. Come on Dmitry, I am not the only who has asked that.
Re: [PHP-DEV] PHP Language Specification
On 24 Jul 2014, at 21:23, Zeev Suraski wrote: > CPython is the name of the implementation, but python.org offers you to > download Python, not CPython. CPython is an internal name kind of like > php-src (more or less). In fact, as an average end user, you'd not know > about CPython at all. Of course. So far as users care, CPython is Python. So far as users care, Zend PHP/ZPHP/CPHP/php-src/vanilla PHP/whatever is PHP. However, from an internals perspective, we need to be able to distinguish the two and this becomes particularly important now due to HHVM and the specification. So, we should decide on a name for the original PHP implementation. -- 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
CPython is the name of the implementation, but python.org offers you to download Python, not CPython. CPython is an internal name kind of like php-src (more or less). In fact, as an average end user, you'd not know about CPython at all. Jython, JyJy, etc. - don't call themselves 'Python', they're implementations of the Python language. Zeev > -Original Message- > From: Andrea Faulds [mailto:a...@ajf.me] > Sent: Thursday, July 24, 2014 11:19 PM > To: Zeev Suraski > Cc: Sara Golemon; Rowan Collins; PHP internals > Subject: Re: [PHP-DEV] PHP Language Specification > > > On 24 Jul 2014, at 21:12, Zeev Suraski wrote: > > > Other opensource languages that have multiple implementations, still > > have the 'official' release with the original name, while other > > implementations have separate, different names that implement 'the XYZ > > language' or 'the ABC spec'. > > > > E.g., there's Jython, Cython, PyPy - but the original Python is still > > Python. > > Python might be a poor example. The "original Python" is called CPython. > > In technical discussions it would be very useful to have a proper name for the > vanilla implementation, even though most people are going to call it PHP > anyway. > -- > Andrea Faulds > http://ajf.me/ > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using stada...@lists.php.net for spec work
I almost suggested to use that list, but I think that the php spec would worth having a dedicated list, without any previous bias/connotation. It could also be surprising for the current subscribers to see a resurrected mailing list with a "slightly" different target audience and topic. On Thu, Jul 24, 2014 at 8:24 PM, Stas Malyshev wrote: > Hi! > > I would like to propose to use list stada...@lists.php.net (which has > been dormant since 2009) for PHP spec work. What do you think? > > -- > 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 > > -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] PHP Language Specification
On 24 Jul 2014, at 21:18, Zeev Suraski wrote: > No, there's no ambiguity at all - 'PHP' is the implementation, as it > always has been. 'PHP language specification' or 'PHP spec' for short is > the specification. Absolutely no ambiguity. So PHP is variously the language (as in PHP language specification) and an implementation (as in PHP). There is definitely an ambiguity. We need to be able to distinguish between PHP (the language/specification) and PHP (the implementation). >> You know, the git repository is called php-src. Why don't we call the >> implementation php-src? > > Well, one reason is that it would be a horrible, horrible name (imagine us > "Happy to announce php-src 5.6!", come on). But another is there's really > absolutely no reason to change the name of PHP to anything at all. There > would be the PHP spec, and there would be PHP. What does PHP mean here? The language? The vanilla implementation? -- 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 24 Jul 2014, at 21:12, Zeev Suraski wrote: > Other opensource languages that have multiple implementations, still have > the 'official' release with the original name, while other implementations > have separate, different names that implement 'the XYZ language' or 'the > ABC spec'. > > E.g., there's Jython, Cython, PyPy - but the original Python is still > Python. Python might be a poor example. The “original Python” is called CPython. In technical discussions it would be very useful to have a proper name for the vanilla implementation, even though most people are going to call it PHP anyway. -- 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
> -Original Message- > From: Andrea Faulds [mailto:a...@ajf.me] > Sent: Thursday, July 24, 2014 11:04 PM > To: Zeev Suraski > Cc: Rowan Collins; internals@lists.php.net > Subject: Re: [PHP-DEV] PHP Language Specification > > > On 24 Jul 2014, at 21:00, Zeev Suraski wrote: > > > I think that the language spec initiative is a great initiative, but > > let's not get carried away and start turning things upside down. This > > would be the 'PHP language specification', not 'PHP'. PHP would > > ideally adhere to it. Other implementation (such as hhvm) would > > probably adhere to them as well - but they would still not be named > > 'PHP', but rather, implementations of the PHP language or the PHP > > language spec. This is consistent with mostly all of the other open > > source scripting languages out there. > > This is unhelpful, however, as it leaves PHP being ambiguous as to whether it > means the implementation or the spec. No, there's no ambiguity at all - 'PHP' is the implementation, as it always has been. 'PHP language specification' or 'PHP spec' for short is the specification. Absolutely no ambiguity. > You know, the git repository is called php-src. Why don't we call the > implementation php-src? Well, one reason is that it would be a horrible, horrible name (imagine us "Happy to announce php-src 5.6!", come on). But another is there's really absolutely no reason to change the name of PHP to anything at all. There would be the PHP spec, and there would be PHP. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
agree, I just don't see any blockers, except for Pierre. Lets wait a week. Thanks, Dmitry. On Fri, Jul 25, 2014 at 12:01 AM, Nikita Popov wrote: > On Thu, Jul 24, 2014 at 9:04 PM, Dmitry Stogov wrote: > >> Hi, >> >> I didn't see any phpng related discussion for a day. >> If we have nothing to discuss, may be we should just the start a voting >> process. :) >> >> It's not a problem for me to wait a week or even month. I just like to >> know. if anyone thinks, that we have any stoppers to start the voting. >> >> Last days we tried to improve https://wiki.php.net/phpng-upgrading >> However, our English is poor and boring. It would be cool, if native >> speakers would improve the docs. (section related to Objects is not ready >> yet). >> > > Our voting RFC prescribes that voting can start no earlier than two weeks > after the RFC announcement (which was three days ago). As this is a big > change and there's no particular rush to get this merged, I'd suggest to > stick with the usual process :) > > Nikita >
RE: [PHP-DEV] PHP Language Specification
> 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). I think it's easy enough to talk about 'PHP' and the 'PHP language specification' or shorten it up as 'PHP spec'. Other opensource languages that have multiple implementations, still have the 'official' release with the original name, while other implementations have separate, different names that implement 'the XYZ language' or 'the ABC spec'. E.g., there's Jython, Cython, PyPy - but the original Python is still Python. Whatever php.net ships, be it based on ZE, hhvm or something else, should be called PHP. It's a lot more than just something that implements the spec - it's the codebase, build process, extensions, SAPI modules, performance, memory footprint, bugs, misfeatures, etc. etc. - everything that has to do with the implementation. > 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 don't recall if it was === or 'is', but regardless, the meaning was absolutely 'Zend is PHP' (as in everything Zend does is PHP), and not 'PHP is Zend'. Regardless, since it was clearly misunderstood by many people we stopped using it :) Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
You talk not about starting the voting, you talk about your opinion. Anyway. No problem I can wait another week and start the voting according to all the rules. Dmitry. On Thu, Jul 24, 2014 at 11:55 PM, Pierre Joye wrote: > > On Jul 24, 2014 9:45 PM, "Dmitry Stogov" wrote: > > > > Vote -1, I won't be surprised. > > > > I'm asking if we have any stoppers to start the voting, if we have > nothing to discuss. > > > > The porting guide is almost ready now, but it never be 100% ready to > someones. > > It is the stopper and not only the migration guide. We need to know what > has been done to do an informed vote. We also need to know what else is > coming, readiness for changes etc. > > Voting now means giving you a blank card and simply accept anything and > expose us to what already happened too many times, rejecting patches with > no good reasons. > > > Thanks. Dmitry. > > > > > > On Thu, Jul 24, 2014 at 11:14 PM, Pierre Joye > wrote: > >> > >> hi Dmitry, > >> > >> On Thu, Jul 24, 2014 at 9:04 PM, Dmitry Stogov wrote: > >> > Hi, > >> > > >> > I didn't see any phpng related discussion for a day. > >> > If we have nothing to discuss, may be we should just the start a > voting > >> > process. :) > >> > > >> > It's not a problem for me to wait a week or even month. I just like to > >> > know. if anyone thinks, that we have any stoppers to start the voting. > >> > > >> > Last days we tried to improve https://wiki.php.net/phpng-upgrading > >> > However, our English is poor and boring. It would be cool, if native > >> > speakers would improve the docs. (section related to Objects is not > ready > >> > yet). > >> > >> The current status of the doc, migration guide, list of changes and > >> explanation will force me to vote -1 at this point. I am very > >> reluctant to give you a blank card and then keep hearing "no" to every > >> 2nd patch we will provide :) > >> > >> Also none of my questions have been answered in the various phpng > >> threads, so it is not like I can vote +1 anyway... > >> > >> Cheers, > >> -- > >> Pierre > >> > >> @pierrejoye | http://www.libgd.org > > > > >
Re: [PHP-DEV] PHP Language Specification
On 24 Jul 2014, at 21:00, Zeev Suraski wrote: > I think that the language spec initiative is a great initiative, but let's > not get carried away and start turning things upside down. This would be > the 'PHP language specification', not 'PHP'. PHP would ideally adhere to > it. Other implementation (such as hhvm) would probably adhere to them as > well - but they would still not be named 'PHP', but rather, > implementations of the PHP language or the PHP language spec. This is > consistent with mostly all of the other open source scripting languages > out there. This is unhelpful, however, as it leaves PHP being ambiguous as to whether it means the implementation or the spec. You know, the git repository is called php-src. Why don’t we call the implementation php-src? -- 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
I think we're overcomplicating things a bit... First, as someone from Zend, I never ever call PHP "Zend PHP". PHP is hardly just the Zend Engine, but also the extensions, SAPI modules, tests, etc - everything that people with php.net accounts work on. In fact if I hear someone saying 'Zend PHP' I'd always correct them, although it's pretty uncommon. If I ever do need to qualify it vs. other implementations, then it's always 'the php.net PHP', not anything else. php.net in that regard isn't a website - it's the whole php.net developer community. The name of this implementation should absolutely remain PHP, not CPHP or ZPHP or anything else, and it's in fact the only piece of software that may call itself PHP as per the PHP license. I think that the language spec initiative is a great initiative, but let's not get carried away and start turning things upside down. This would be the 'PHP language specification', not 'PHP'. PHP would ideally adhere to it. Other implementation (such as hhvm) would probably adhere to them as well - but they would still not be named 'PHP', but rather, implementations of the PHP language or the PHP language spec. This is consistent with mostly all of the other open source scripting languages out there. When we talk about a bug in PHP 5.6.2 or a new feature in PHP 9.9, it will absolutely refer to that thing you download from www.php.net (or packages based off of it) - not the language spec. Zeev > -Original Message- > From: Andrea Faulds [mailto:a...@ajf.me] > Sent: Thursday, July 24, 2014 5:29 PM > To: Rowan Collins > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] PHP Language Specification > > > On 24 Jul 2014, at 14:40, Rowan Collins wrote: > > > Incidentally, that's another question: some people like to make clear that > the Zend Engine isn't actually the language implementation, it just *powers* > the implementation. In which case, what *should* the implementation be > called? > > That's actually an important question. I always tend to say "Zend PHP" here, > but I'm a little bit uneasy about having Zend in the name. Perhaps "the > PHP.net implementation"? "PHP Group implementation"? "PHP reference > implementation"? > > We could take a leaf from Python's book and call it CPHP :) > > -- > Andrea Faulds > http://ajf.me/ > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: > http://www.php.net/unsub.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 Thu, Jul 24, 2014 at 9:04 PM, Dmitry Stogov wrote: > Hi, > > I didn't see any phpng related discussion for a day. > If we have nothing to discuss, may be we should just the start a voting > process. :) > > It's not a problem for me to wait a week or even month. I just like to > know. if anyone thinks, that we have any stoppers to start the voting. > > Last days we tried to improve https://wiki.php.net/phpng-upgrading > However, our English is poor and boring. It would be cool, if native > speakers would improve the docs. (section related to Objects is not ready > yet). > Our voting RFC prescribes that voting can start no earlier than two weeks after the RFC announcement (which was three days ago). As this is a big change and there's no particular rush to get this merged, I'd suggest to stick with the usual process :) Nikita
Re: [PHP-DEV] Using stada...@lists.php.net for spec work
On 7/24/14, 1:25 PM, Stas Malyshev wrote: Hi! I would like to propose to use list stada...@lists.php.net (which has been dormant since 2009) for PHP spec work. What do you think? Of course it's standa...@lists.php.net. standa...@lists.php.net was the original home of what eventually morphed into the PHP-FIG. I think repurposing it for a PHP standard-spec discussion group, especially if it's a collaboration of different PHP engine implementers, would be a nice homage. --Larry Garfield -- 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 Jul 24, 2014 9:45 PM, "Dmitry Stogov" wrote: > > Vote -1, I won't be surprised. > > I'm asking if we have any stoppers to start the voting, if we have nothing to discuss. > > The porting guide is almost ready now, but it never be 100% ready to someones. It is the stopper and not only the migration guide. We need to know what has been done to do an informed vote. We also need to know what else is coming, readiness for changes etc. Voting now means giving you a blank card and simply accept anything and expose us to what already happened too many times, rejecting patches with no good reasons. > Thanks. Dmitry. > > > On Thu, Jul 24, 2014 at 11:14 PM, Pierre Joye wrote: >> >> hi Dmitry, >> >> On Thu, Jul 24, 2014 at 9:04 PM, Dmitry Stogov wrote: >> > Hi, >> > >> > I didn't see any phpng related discussion for a day. >> > If we have nothing to discuss, may be we should just the start a voting >> > process. :) >> > >> > It's not a problem for me to wait a week or even month. I just like to >> > know. if anyone thinks, that we have any stoppers to start the voting. >> > >> > Last days we tried to improve https://wiki.php.net/phpng-upgrading >> > However, our English is poor and boring. It would be cool, if native >> > speakers would improve the docs. (section related to Objects is not ready >> > yet). >> >> The current status of the doc, migration guide, list of changes and >> explanation will force me to vote -1 at this point. I am very >> reluctant to give you a blank card and then keep hearing "no" to every >> 2nd patch we will provide :) >> >> Also none of my questions have been answered in the various phpng >> threads, so it is not like I can vote +1 anyway... >> >> Cheers, >> -- >> Pierre >> >> @pierrejoye | http://www.libgd.org > >
Re: [PHP-DEV] RFC: Move phpng to master
Vote -1, I won't be surprised. I'm asking if we have any stoppers to start the voting, if we have nothing to discuss. The porting guide is almost ready now, but it never be 100% ready to someones. Thanks. Dmitry. On Thu, Jul 24, 2014 at 11:14 PM, Pierre Joye wrote: > hi Dmitry, > > On Thu, Jul 24, 2014 at 9:04 PM, Dmitry Stogov wrote: > > Hi, > > > > I didn't see any phpng related discussion for a day. > > If we have nothing to discuss, may be we should just the start a voting > > process. :) > > > > It's not a problem for me to wait a week or even month. I just like to > > know. if anyone thinks, that we have any stoppers to start the voting. > > > > Last days we tried to improve https://wiki.php.net/phpng-upgrading > > However, our English is poor and boring. It would be cool, if native > > speakers would improve the docs. (section related to Objects is not ready > > yet). > > The current status of the doc, migration guide, list of changes and > explanation will force me to vote -1 at this point. I am very > reluctant to give you a blank card and then keep hearing "no" to every > 2nd patch we will provide :) > > Also none of my questions have been answered in the various phpng > threads, so it is not like I can vote +1 anyway... > > Cheers, > -- > Pierre > > @pierrejoye | http://www.libgd.org >
Re: [PHP-DEV] PHP Language Specification
On Thu, Jul 24, 2014 at 12:29 PM, Rowan Collins 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Language Specification
On 24/07/2014 19:28, Pierre Joye wrote: >>We could take a leaf from Python’s book and call it CPHP :) > > >Or ZPHP? Implying the PHP implementation built on Zend, but not directly >using the Zend trademark? Call it php.net or something like that, The problem with php.net is that it's also the name of the website, so it still doesn't unambiguously identify the implementation/distribution as opposed to all manner of other things that are organised via that site. It would be nice to have a snappy way of referring to it without resort to awkward phrases like "the php.net implementation of PHP". There's also the awkward fact that in other circumstances, a ".net" suffix would imply an implementation for the .net framework, which instead exists under the name Phalanger. 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. The only other defining feature I can think of is that it's the original and reference implementation, so a name suggesting that might work, like "PHP Prime" or "proto-PHP" (somebody may be able to think of something better with the same thought behind it...) The only other way to avoid saying "PHP 5.6.1 is an implementation of PHP 5.6" would be to call the specification itself something other than PHP, as with "POSIX" and "ECMAScript". I'm not at all keen on that idea, though. At the end of the day, we can muddle through, but it might make certain discussions and documentation clearer if the two can be clearly distinguished. -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
hi Dmitry, On Thu, Jul 24, 2014 at 9:04 PM, Dmitry Stogov wrote: > Hi, > > I didn't see any phpng related discussion for a day. > If we have nothing to discuss, may be we should just the start a voting > process. :) > > It's not a problem for me to wait a week or even month. I just like to > know. if anyone thinks, that we have any stoppers to start the voting. > > Last days we tried to improve https://wiki.php.net/phpng-upgrading > However, our English is poor and boring. It would be cool, if native > speakers would improve the docs. (section related to Objects is not ready > yet). The current status of the doc, migration guide, list of changes and explanation will force me to vote -1 at this point. I am very reluctant to give you a blank card and then keep hearing "no" to every 2nd patch we will provide :) Also none of my questions have been answered in the various phpng threads, so it is not like I can vote +1 anyway... 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] Using stada...@lists.php.net for spec work
On Thu, Jul 24, 2014 at 12:01 PM, Hannes Magnusson wrote: > What sort of problems are they having? Not getting the challenge mail? > > Even if I'd bulk register some people to this list, they would not be > able to send an email to until they've replied to the 'mail > challenge'.. > Please look in their spam folder... > tbh, I'm not clear, having been subscribed to internals@ since it was called php-dev@ I didn't put any effort into reproing it till today. Speaking of, I did just successfully subscribe myself to standards@ (without any trouble) using the direct ezmlm interface. Maybe they were using the web form on php.net? I dunno. Maybe it's just PEBKAC -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Move phpng to master
The "the" before "start" is a mistake :) On Thu, Jul 24, 2014 at 11:04 PM, Dmitry Stogov wrote: > Hi, > > I didn't see any phpng related discussion for a day. > If we have nothing to discuss, may be we should just the start a voting > process. :) > > It's not a problem for me to wait a week or even month. I just like to > know. if anyone thinks, that we have any stoppers to start the voting. > > Last days we tried to improve https://wiki.php.net/phpng-upgrading > However, our English is poor and boring. It would be cool, if native > speakers would improve the docs. (section related to Objects is not ready > yet). > > Thanks. Dmitry. > > > > On Thu, Jul 24, 2014 at 12:27 AM, Zeev Suraski wrote: > >> > -Original Message- >> > From: Stas Malyshev [mailto:smalys...@sugarcrm.com] >> > Sent: Wednesday, July 23, 2014 8:00 AM >> > To: Zeev Suraski; PHP internals >> > Subject: Re: [PHP-DEV] RFC: Move phpng to master >> > >> > I think before we do that we need to do much better documentation around >> > the changes in the engine. I know that in the past we followed the "code >> > is >> > documentation" pattern, but the code there becomes more and more dense, >> > with macros upon macros upon macros, and myriads of micro-optimizations >> > which make sense only in specific context. Absent that context and >> > documentation, understanding what is going on becomes much harder and so >> > becomes dealing with that code. Some of the changes right now are >> > partially >> > documented in https://wiki.php.net/phpng-int, some (like parameter >> parsing >> > API) not documented at all. Given that, I'm not even sure I understand >> > what >> > phpng is right now - as I didn't have time to parse every commit during >> > active >> > development. So it would be nice to have some internal docs if we want >> > people to form an informed opinion about what is being proposed. >> > >> > And, of course, the porting guide for extension authors is another >> > required >> > part. I know the phpng team did great work porting the extensions, but >> > people >> > would need to support them and add the new ones, so it is a must. >> >> As Dmitry mentioned, this is something we're going to work on (with >> primary >> focus around the porting guide, and secondary focus on extending the >> internals document). >> >> Zeev >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >
Re: [PHP-DEV] RFC: Move phpng to master
Hi, I didn't see any phpng related discussion for a day. If we have nothing to discuss, may be we should just the start a voting process. :) It's not a problem for me to wait a week or even month. I just like to know. if anyone thinks, that we have any stoppers to start the voting. Last days we tried to improve https://wiki.php.net/phpng-upgrading However, our English is poor and boring. It would be cool, if native speakers would improve the docs. (section related to Objects is not ready yet). Thanks. Dmitry. On Thu, Jul 24, 2014 at 12:27 AM, Zeev Suraski wrote: > > -Original Message- > > From: Stas Malyshev [mailto:smalys...@sugarcrm.com] > > Sent: Wednesday, July 23, 2014 8:00 AM > > To: Zeev Suraski; PHP internals > > Subject: Re: [PHP-DEV] RFC: Move phpng to master > > > > I think before we do that we need to do much better documentation around > > the changes in the engine. I know that in the past we followed the "code > > is > > documentation" pattern, but the code there becomes more and more dense, > > with macros upon macros upon macros, and myriads of micro-optimizations > > which make sense only in specific context. Absent that context and > > documentation, understanding what is going on becomes much harder and so > > becomes dealing with that code. Some of the changes right now are > > partially > > documented in https://wiki.php.net/phpng-int, some (like parameter > parsing > > API) not documented at all. Given that, I'm not even sure I understand > > what > > phpng is right now - as I didn't have time to parse every commit during > > active > > development. So it would be nice to have some internal docs if we want > > people to form an informed opinion about what is being proposed. > > > > And, of course, the porting guide for extension authors is another > > required > > part. I know the phpng team did great work porting the extensions, but > > people > > would need to support them and add the new ones, so it is a must. > > As Dmitry mentioned, this is something we're going to work on (with primary > focus around the porting guide, and secondary focus on extending the > internals document). > > Zeev > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] Using stada...@lists.php.net for spec work
What sort of problems are they having? Not getting the challenge mail? Even if I'd bulk register some people to this list, they would not be able to send an email to until they've replied to the 'mail challenge'.. Please look in their spam folder... -Hannes On Thu, Jul 24, 2014 at 11:30 AM, Sara Golemon wrote: > On Thu, Jul 24, 2014 at 11:25 AM, Stas Malyshev > wrote: >> I would like to propose to use list standa...@lists.php.net (which has >> been dormant since 2009) for PHP spec work. What do you think? >> > Big +1 on this. btw, a lot of folks on the HHVM team have been having > trouble getting subcribed to lists.php.net, if I sent you a set of > email addresses and lists, could you help out with some bulk > subscriptions (including standards@)? > > -Sara > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using stada...@lists.php.net for spec work
On 24/07/2014 20:25, Andrea Faulds wrote: On 24 Jul 2014, at 19:24, Stas Malyshev wrote: Hi! I would like to propose to use list stada...@lists.php.net (which has been dormant since 2009) for PHP spec work. What do you think? Did you typo both your subject and body, or is the list actually called stadards, not standards? :) Damn copy/paste :-p. +1 for me, good idea. -- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using standa...@lists.php.net for spec work
Hi! > Big +1 on this. btw, a lot of folks on the HHVM team have been having > trouble getting subcribed to lists.php.net, if I sent you a set of > email addresses and lists, could you help out with some bulk > subscriptions (including standards@)? I guess that would be folks on syst...@php.net, I personally have no access there. -- 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] Using stada...@lists.php.net for spec work
On Thu, Jul 24, 2014 at 11:25 AM, Stas Malyshev wrote: > I would like to propose to use list standa...@lists.php.net (which has > been dormant since 2009) for PHP spec work. What do you think? > Big +1 on this. btw, a lot of folks on the HHVM team have been having trouble getting subcribed to lists.php.net, if I sent you a set of email addresses and lists, could you help out with some bulk subscriptions (including standards@)? -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Language Specification
On Thu, Jul 24, 2014 at 4:44 PM, Rowan Collins wrote: > Andrea Faulds wrote (on 24/07/2014): > >> On 24 Jul 2014, at 14:40, Rowan Collins wrote: >> >>> Incidentally, that's another question: some people like to make clear >>> that the Zend Engine isn't actually the language implementation, it just >>> *powers* the implementation. In which case, what *should* the implementation >>> be called? >> >> That’s actually an important question. I always tend to say “Zend PHP” >> here, but I’m a little bit uneasy about having Zend in the name. Perhaps >> “the PHP.net implementation”? “PHP Group implementation”? “PHP reference >> implementation”? >> >> We could take a leaf from Python’s book and call it CPHP :) > > > Or ZPHP? Implying the PHP implementation built on Zend, but not directly > using the Zend trademark? Call it php.net or something like that, 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. 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] Re: PHP Language Specification
On Thu, Jul 24, 2014 at 10:48 AM, Stas Malyshev wrote: > Is it also possible to pub description of how to render it on > wiki.php.net so that if someone prepares a big patch they'd be able to > test they didn't mess up before committing? > The repo layout he's working on includes a tools/ directory for generating output, so yeah. One would be able to run a quick script to produce HTML or something verifiable. If it stays Markdown as the source format, then the PR will of course also be visible in the branch straight from github. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using stada...@lists.php.net for spec work
On 24 Jul 2014, at 19:24, Stas Malyshev wrote: > Hi! > > I would like to propose to use list stada...@lists.php.net (which has > been dormant since 2009) for PHP spec work. What do you think? Did you typo both your subject and body, or is the list actually called stadards, not standards? :) -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using stada...@lists.php.net for spec work
Hi! > I would like to propose to use list stada...@lists.php.net (which has > been dormant since 2009) for PHP spec work. What do you think? Of course it's standa...@lists.php.net. -- 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
[PHP-DEV] Using stada...@lists.php.net for spec work
Hi! I would like to propose to use list stada...@lists.php.net (which has been dormant since 2009) for PHP spec work. What do you think? -- 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] Re: PHP Language Specification
Hi! > Progress is being made on getting it all into a collaborative format. > Our documentation guy is currently favoring markdown as an initial > format which is able to express everything currently in the spec, and > he's planning to build some rendering scripts that'll be able to > produce other formats from it if we want to swap later. Here's a > sample of what that ends up looking like: > https://pbs.twimg.com/media/BtUkSVLCEAA3Lfq.png:large This looks pretty good. Thanks! Is it also possible to pub description of how to render it on wiki.php.net so that if someone prepares a big patch they'd be able to test they didn't mess up before committing? -- 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
[PHP-DEV] Re: PHP Language Specification
On Tue, Jul 22, 2014 at 12:50 PM, Sara Golemon wrote: > Just announced something at OSCON that's probably going to get a lot > of folks talking and making assumptions, so before things get out of > hand, I want to provide some context. > Progress is being made on getting it all into a collaborative format. Our documentation guy is currently favoring markdown as an initial format which is able to express everything currently in the spec, and he's planning to build some rendering scripts that'll be able to produce other formats from it if we want to swap later. Here's a sample of what that ends up looking like: https://pbs.twimg.com/media/BtUkSVLCEAA3Lfq.png:large The plan at the moment is to put it at https://github.com/phplang/php-spec with a CC0 license (public domain) and give push karma to those who currently have ZendEngine karma. This lets us react quickly to PRs in this early part of the draft, while tying "ownership" of the language to those who have been writing it. For portability, we'll be pushing renderings of the spec to a Github Pages site at http://phplang.github.io -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php interactive shell: save history on SIGINT exit
On Wed, 2014-07-23 at 17:08 +0400, Dmitry Saprykin wrote: > Yes, you are right. append_history is not suitable for libedit. I left > write_history call for libedit. Committed and pushed in a slightly modified form (variable declarations should be on top of a block) http://git.php.net/?p=php-src.git;a=commitdiff;h=d491b2f916d061666d9ff1cb5bdc484961b82db0 johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] FW: PowerPC64 support
@Andrea, What @Lior said is completely right, as you can see below: https://www.power.org/power-org-corporate-members http://openpowerfoundation.org/membership/current-members From: Lior Kaplan Sent: Thursday, July 24, 2014 11:58 To: Andrea Faulds Cc: Gustavo Frederico Temple Pedrosa; internals@lists.php.net; hannes.magnus...@gmail.com Subject: Re: [PHP-DEV] FW: PowerPC64 support On Thu, Jul 24, 2014 at 5:23 PM, Andrea Faulds mailto:a...@ajf.me>> wrote: On 24 Jul 2014, at 12:17, Gustavo Frederico Temple Pedrosa mailto:gustavo.pedr...@eldorado.org.br>> wrote: > I and my team are involved in changes for architecture-specific > implementations, > specifically PowerPC64, in favor of expand the support and performance in the > PHP. How widely used is the PowerPC64 architecture? Is it really worth adding yet another set of inline asm that will have to be updated if we changed these operators? For the first question - you'll probably will see an increase due to the OpenPower and IBM's POWER8. Kaplan
Re: [PHP-DEV] VCS Account Request: nishantcbse
On Thu, Jul 24, 2014 at 3:53 PM, nishant kumar wrote: > Maintaining an official, bundled PHP extension > Maintaining php.net > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > hi, what extension would be that? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] FW: PowerPC64 support
On Thu, Jul 24, 2014 at 5:23 PM, Andrea Faulds wrote: > > On 24 Jul 2014, at 12:17, Gustavo Frederico Temple Pedrosa < > gustavo.pedr...@eldorado.org.br> wrote: > > > I and my team are involved in changes for architecture-specific > implementations, > > specifically PowerPC64, in favor of expand the support and performance > in the PHP. > > How widely used is the PowerPC64 architecture? Is it really worth adding > yet another set of inline asm that will have to be updated if we changed > these operators? > For the first question - you'll probably will see an increase due to the OpenPower and IBM's POWER8. Kaplan
Re: [PHP-DEV] PHP Language Specification
On Thu, Jul 24, 2014 at 4:28 PM, Andrea Faulds wrote: > > On 24 Jul 2014, at 14:40, Rowan Collins wrote: > > > Incidentally, that's another question: some people like to make clear > that the Zend Engine isn't actually the language implementation, it just > *powers* the implementation. In which case, what *should* the > implementation be called? > > That’s actually an important question. I always tend to say “Zend PHP” > here, but I’m a little bit uneasy about having Zend in the name. Perhaps > “the PHP.net implementation”? “PHP Group implementation”? “PHP reference > implementation”? > > We could take a leaf from Python’s book and call it CPHP :) > > -- > Andrea Faulds > http://ajf.me/ > I would say reference implementation or vanilla php. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] PHP Language Specification
On 24 Jul 2014, at 15:44, Rowan Collins wrote: > Or ZPHP? Implying the PHP implementation built on Zend, but not directly > using the Zend trademark? I like that suggestion. Reminds me of my CPHP one, but it makes more sense. So we’d have PHP 5.6 and ZPHP 5.6.1 (ZPHP would track major and minor spec versions). That could work, right? -- 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
Andrea Faulds wrote (on 24/07/2014): On 24 Jul 2014, at 14:40, Rowan Collins wrote: Incidentally, that's another question: some people like to make clear that the Zend Engine isn't actually the language implementation, it just *powers* the implementation. In which case, what *should* the implementation be called? That’s actually an important question. I always tend to say “Zend PHP” here, but I’m a little bit uneasy about having Zend in the name. Perhaps “the PHP.net implementation”? “PHP Group implementation”? “PHP reference implementation”? We could take a leaf from Python’s book and call it CPHP :) Or ZPHP? Implying the PHP implementation built on Zend, but not directly using the Zend trademark? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 final release
On Wed, 2014-07-23 at 18:22 -0400, George Wang wrote: > Hi, > > I have a request to include our latest sapi/litespeed V6.6 to the EOL > PHP 5.3 release. I thought it was EOL already. PHP 5.3 is in extended support and only receives security related fixes. In general people should use newer versions which have more bug fixes and are faster. I don't think these updates qualify. > We had some difficult to commit our LiteSpeed SAPI code into PHP > source repository before, so it is lagging behind our office release. What kind of issues? johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Language Specification
On 24 Jul 2014, at 14:40, Rowan Collins wrote: > Incidentally, that's another question: some people like to make clear that > the Zend Engine isn't actually the language implementation, it just *powers* > the implementation. In which case, what *should* the implementation be called? That’s actually an important question. I always tend to say “Zend PHP” here, but I’m a little bit uneasy about having Zend in the name. Perhaps “the PHP.net implementation”? “PHP Group implementation”? “PHP reference implementation”? We could take a leaf from Python’s book and call it CPHP :) -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On 24 Jul 2014, at 13:20, Simon Schick wrote: >> Conversion is allowed only if data-loss does not happen. There are a few >> exceptions (objects using __toString, strings containing leading numerics, >> etc). Here's a table of examples. > > But if you look at the table, strings containing leading numbers are > not allowed. Good catch, fixed. > And just as a thought: What about objects where the __toString method > returns a string like "42"? Would that also be accepted as an > argument, that just accepts integers? No it wouldn’t, as that’s not what cast_object does, existing conversion functions do, or what the patch does at present. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FW: PowerPC64 support
On 24 Jul 2014, at 12:17, Gustavo Frederico Temple Pedrosa wrote: > I and my team are involved in changes for architecture-specific > implementations, > specifically PowerPC64, in favor of expand the support and performance in the > PHP. How widely used is the PowerPC64 architecture? Is it really worth adding yet another set of inline asm that will have to be updated if we changed these operators? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Request: nishantcbse
Maintaining an official, bundled PHP extension Maintaining php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Language Specification
Ivan Enderlin @ Hoa wrote (on 24/07/2014): Taking the example of XML, CSS, HTML, ECMAScript or other languages (maybe the JVM, I don't know exactly), there is version numbers for the specification, that are different of the version numbers of the implementations. Even more, the version of the implementations is most of the time unknown (what is the version of SpiderMonkey or V8 for ECMAScript x? We don't really know). I think this only really matters if it's likely that the Zend implementation diverges from the specification, such as by a feature being implemented in HHVM and agreed to be standard, but no release of Zend produced supporting that feature. And that in turn implies a separate stewardship and decision-making process for the implementation and the specification, which would be a major change in process. Incidentally, that's another question: some people like to make clear that the Zend Engine isn't actually the language implementation, it just *powers* the implementation. In which case, what *should* the implementation be called? -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Language Specification
On 23/07/2014 22:59, Ben Ramsey wrote: This got me thinking about the whole version number debate. With a language specification, to what does the version number refer? The state of the language specification, or the state of a given implementation of the specification? Right now, the number refers to the state of the PHP Group implementation, and implementations like HippyVM and HHVM say that they are compatible with Zend PHP 5.x. Will we version the language specification separately, and individual releases of various implementations (including the PHP Group implementation) will state that they are compatible with version X of the specification? This is exactly what I said in “a lot of questions remain open” in my previous mail [1]. Taking the example of XML, CSS, HTML, ECMAScript or other languages (maybe the JVM, I don't know exactly), there is version numbers for the specification, that are different of the version numbers of the implementations. Even more, the version of the implementations is most of the time unknown (what is the version of SpiderMonkey or V8 for ECMAScript x? We don't really know). In the case of PHP, this is different because the word “PHP” was previously (yes, it's done) representing the language **and** the implementation. Consequently, we can't start with PHP1. 1. A solution would be to start with PHP6 (and 7, I don't know…) for the specification, and then, the version of the implementations will have no importance (HHVM1.3, ZendEngine3.0, whatever you want). 2. Another solution is to refer to the PHP version with a “new name”, something like “PHPx” or “PHPv”, so we will have "PHPx1”, “PHPx2” etc. 3. A final solution I see is to refer to PHP with “PHP1” which will be equivalent to “PHP6.1”, exactly as Java7 which is in reality Java1.7, but when they will introduce Java2.x, they will encounter a problem… My favorite solution is the 2nd one. Moreover, what about (let's say with PHPx) PHPx1.2.3? Does it make sense to have x.y.z for a language specification? We don't see it very often. Actually, x.y is enough I would say (XML1.1, Java1.7 etc.), I don't know any x.y.z language specification. Another problem to solve: what about the `php_version` function, the `PHP_VERSION_ID` constant etc. If an implementation (a VM) respects the specification, testing the version of the specification does not make sense anymore, except in edge-cases, so we will really test the version of language. Do we keep these functions and constants? Do we introduce new ones? The specification might define the format of some functions or constants to get the versions of the implementation, for example: `PHP_VM_VERSION_ID` along with `PHP_VM_NAME` (something similar to what PHP does with SAPI). Thoughts? [1] http://marc.info/?l=php-internals&m=140612071919140&w=2 -- Ivan Enderlin Developer of Hoa http://hoa-project.net/ PhD. at DISC/Femto-ST (Vesontio) and INRIA (Cassis) http://disc.univ-fcomte.fr/ and http://www.inria.fr/ Member of HTML and WebApps Working Group of W3C http://w3.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
> My main concern about the RFC the way it stands right now is that the > current direction involves E_RECOVERABLE_ERROR instead of E_STRICT or E_CAST > for data loss. This results in both consistency issues with casting as well > as incompatibility with the dynamic nature of PHP scalars. I know the RFC > author (Andrea) disagrees with me about it, but I think we need to find a > way to put this into a much wider decision. Probably the most practical > thing to do is to put it as a secondary question in the RFC, although those > can be tricky. > > Zeev Hi, all I looked again at the RFC .. Can someone please update the description at the section "Conversion Rules"? This is quoted from the document: > Conversion is allowed only if data-loss does not happen. There are a few > exceptions (objects using __toString, strings containing leading numerics, > etc). Here's a table of examples. But if you look at the table, strings containing leading numbers are not allowed. And just as a thought: What about objects where the __toString method returns a string like "42"? Would that also be accepted as an argument, that just accepts integers? Sounds crazy, but as strings, only containing numbers, are accepted as integer, we have to take a decision here and write it down. Bye Simon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.5.15 is released
Hello! The PHP development team announces the immediate availability of PHP 5.5.15. This fixes some bugs against 5.5.14 and addresses one CVE in SPL. All PHP 5.5 users are encouraged to upgrade to this version. For source downloads of PHP 5.5.15 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/ The full list of changes is recorded in the ChangeLog: http://www.php.net/ChangeLog-5.php#5.5.15 Julien Pauli & David Soria Para
[PHP-DEV] FW: PowerPC64 support
Hi internals! I and my team are involved in changes for architecture-specific implementations, specifically PowerPC64, in favor of expand the support and performance in the PHP. See also: https://github.com/php/php-src/pull/734 (PowerPC64 support in safe_address function) https://github.com/php/php-src/pull/735 (PowerPC64 support for operators with overflow check) https://github.com/php/php-src/pull/736 (PowerPC64 support in long multiplication) https://github.com/php/php-src/pull/737 (PowerPC64 support for counting zeros) Please review :) Thanks, Gustavo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On Thu, Jul 24, 2014 at 12:25 PM, Zeev Suraski wrote: > We definitely do not.. Well, open list, if some like to discuss it, we can. But see below, it may not be necessary. > To elaborate, the notion that we already have strict class types for > classes, so we should have the same thing for scalar makes no sense at all. > Here's why: > > 1. If it was the case, we'd add this right when we added class type hints > (strict class types). Just like we'd to add full OO concepts right with 5.0. > 3. As I stated already, 'Dynamic Typing defines PHP, class type hints do > not'. Class type hints were added at a *MUCH* later stage, as a part of the > major rollout of the new object model of PHP 5. It was actually agreed that > the *only* way we'd add such type hints is if we weren't going to have them > for scalar types. > > What we have on the table right now - casting type hints - can be made to > behave in a way that's consistent with the dynamic typing nature of PHP. Except for the cases I listed in my 2nd mail, which you certainly did not read. However, my mistake, I had an outdated version of the RFC and clearing my local cache shows me the actual one, which matches 100% what I would like to see and wrote in my replies in this thread. > My main concern about the RFC the way it stands right now is that the > current direction involves E_RECOVERABLE_ERROR instead of E_STRICT or E_CAST > for data loss. This results in both consistency issues with casting as well > as incompatibility with the dynamic nature of PHP scalars. I know the RFC > author (Andrea) disagrees with me about it, but I think we need to find a > way to put this into a much wider decision. Probably the most practical > thing to do is to put it as a secondary question in the RFC, although those > can be tricky. I do not like these errors either, I would prefer to have the same than with class arguments, consistent, easy to catch for the developers. So yes, maybe a 2nd question about how bad arguments should be handled would be a good thing. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
> -Original Message- > From: Stas Malyshev [mailto:smalys...@sugarcrm.com] > Sent: Thursday, July 24, 2014 12:04 PM > To: Pierre Joye > Cc: PHP internals > Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening) > > That's called strict typing and was discussed many times. Do we really > want > another round of repeating the same arguments? We definitely do not.. To elaborate, the notion that we already have strict class types for classes, so we should have the same thing for scalar makes no sense at all. Here's why: 1. If it was the case, we'd add this right when we added class type hints (strict class types). 2. The fact of the matter is that we did not. Why not? Because scalars in PHP behave in an inherently different way. 3. As I stated already, 'Dynamic Typing defines PHP, class type hints do not'. Class type hints were added at a *MUCH* later stage, as a part of the major rollout of the new object model of PHP 5. It was actually agreed that the *only* way we'd add such type hints is if we weren't going to have them for scalar types. What we have on the table right now - casting type hints - can be made to behave in a way that's consistent with the dynamic typing nature of PHP. My main concern about the RFC the way it stands right now is that the current direction involves E_RECOVERABLE_ERROR instead of E_STRICT or E_CAST for data loss. This results in both consistency issues with casting as well as incompatibility with the dynamic nature of PHP scalars. I know the RFC author (Andrea) disagrees with me about it, but I think we need to find a way to put this into a much wider decision. Probably the most practical thing to do is to put it as a secondary question in the RFC, although those can be tricky. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Deprecating GD functions imagettftext/bbox
On 24.07.2014 09:13, Pierre Joye wrote: > hi, > > On Tue, Jul 22, 2014 at 9:01 PM, Lonny Kapelushnik wrote: >> Morning, >> >> I propose deprecating two GD functions: imagettftext and imagettfbbox. >> >> The reasons I would like to deprecate them are: >> 1. Their functionality is a subset of imagefttext and imageftbbox >> 2. The imagettf* functions have the same requirements as the imageft* >> functions >> 3. The imagettf* functions parameters are compatible with the imageft* >> functions parameters As I said on IRC, I think the least invasive action would be to make them true aliases (so that the ones with less parameters act exactly as the ones with more) and put that into the docs. This doesn't contradict future removal. Greetings, Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On Thu, Jul 24, 2014 at 11:03 AM, Pierre Joye wrote:
> On Thu, Jul 24, 2014 at 10:52 AM, Pierre Joye wrote:
>> On Thu, Jul 24, 2014 at 10:42 AM, Patrick Schaaf wrote:
>>> Hi,
>>>
>>> there is, it seems, something missing from both the RFC and the
>>> discussion, as far as I read it. Sorry if it came up before, it was a huge
>>> amount of mails...
>>>
>>> How does the proposal affect method compatibility between
>>> subclasses and baseclasses? Will two methods there, differing in the
>>> scalar type annotations of one of their arguments, elicit STRICT
>>> warnings, like object type annotations do?
>>
>> I think it should behave like class arguments do.
>
> I should be more precise :)
>
> say:
>
> function i(integer $i)
> function f(float $f)
> function s(string $s)
>
> $i = 12;
> $f = 1.234;
> $s = "abcdef";
>
> For integer arguments:
>
> Works:
> i($i);
>
> Fails:
> i($f);
> i($s);
> i(new StdClass);
>
> float fails as the argument cannot be an integer without lost of
> information. It is a mis-usage of this function argument and the
> intend of the caller can only be guessed and can only lead to bugs.
>
> For float:
> Works:
> f($i);
> f($f);
> integer is, if I take the class behavior as example, like a float,
> same "interface", fully compatible.
>
> Fails:
> f($s);
> i(new StdClass);
>
> For string, every scalar should work as both float and integer are
> easily converted to string, we can compare them to objects with a
> __toString method. I could live with strict too here but implicit
> string conversion makes sense here. Float precision setting is used
> for the decimal precision.
>
> Arrays and objects without __toString fails, obvioulsy.
and to clarify this, after I got some questions/comments on irc etc.:
f.e.
foo(int $a) {
var_dump($a===123);
}
foo(123) >> true
foo("123") >> true
foo("123a")>> error, bad arg
same for float. The cast happens, it would not make sense if not :)
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On Thu, Jul 24, 2014 at 11:03 AM, Stas Malyshev wrote: > Hi! > >> I think it should behave like class arguments do. > > That's called strict typing and was discussed many times. Do we really > want another round of repeating the same arguments? As I said, yes it was discussed, and yes I think it makes sense to consider it. I won't discuss or battle that to hell tho', it is only the way it my humble opinion. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On Thu, Jul 24, 2014 at 10:52 AM, Pierre Joye wrote: > On Thu, Jul 24, 2014 at 10:42 AM, Patrick Schaaf wrote: >> Hi, >> >> there is, it seems, something missing from both the RFC and the >> discussion, as far as I read it. Sorry if it came up before, it was a huge >> amount of mails... >> >> How does the proposal affect method compatibility between >> subclasses and baseclasses? Will two methods there, differing in the >> scalar type annotations of one of their arguments, elicit STRICT >> warnings, like object type annotations do? > > I think it should behave like class arguments do. I should be more precise :) say: function i(integer $i) function f(float $f) function s(string $s) $i = 12; $f = 1.234; $s = "abcdef"; For integer arguments: Works: i($i); Fails: i($f); i($s); i(new StdClass); float fails as the argument cannot be an integer without lost of information. It is a mis-usage of this function argument and the intend of the caller can only be guessed and can only lead to bugs. For float: Works: f($i); f($f); integer is, if I take the class behavior as example, like a float, same "interface", fully compatible. Fails: f($s); i(new StdClass); For string, every scalar should work as both float and integer are easily converted to string, we can compare them to objects with a __toString method. I could live with strict too here but implicit string conversion makes sense here. Float precision setting is used for the decimal precision. Arrays and objects without __toString fails, obvioulsy. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
Hi! > I think it should behave like class arguments do. That's called strict typing and was discussed many times. Do we really want another round of repeating the same arguments? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On Thu, Jul 24, 2014 at 10:42 AM, Patrick Schaaf wrote: > Hi, > > there is, it seems, something missing from both the RFC and the > discussion, as far as I read it. Sorry if it came up before, it was a huge > amount of mails... > > How does the proposal affect method compatibility between > subclasses and baseclasses? Will two methods there, differing in the > scalar type annotations of one of their arguments, elicit STRICT > warnings, like object type annotations do? I think it should behave like class arguments do. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
Hi, there is, it seems, something missing from both the RFC and the discussion, as far as I read it. Sorry if it came up before, it was a huge amount of mails... How does the proposal affect method compatibility between subclasses and baseclasses? Will two methods there, differing in the scalar type annotations of one of their arguments, elicit STRICT warnings, like object type annotations do? I'm undecided about what would be the "right thing" in that regard, but I think it should be clarified. best regards Patrick
Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
On Jul 24, 2014 10:34 AM, "Patrick Schaaf" wrote: > > > The argument saying that it is not the PHP way is somehow incorrect > > > here, given that we already do that for classe. The type jungling > > > makes sense in implementations, as it always was but argument passing > > > and validation have been a source of pain since very long. I could > > > imagine one exception with the "numeric" type, which could accept > > > anything and got converted to integer/numeric values, like "1235ab" or > > > other weird things. > > > > Personal opinion of a nonvoter, just for the record :) > > > > The fact that roughly everybody in the strict-and-validation camp in the recent discussions, adds in a different view on "with the exception of", very very strongly suggests that the strict-and-validation POV is wrong wrong wrong. > I wrote "I could imagine" not "I want or prefer" the numeric one. To me being strict is what I would like to see.
Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
> The argument saying that it is not the PHP way is somehow incorrect > here, given that we already do that for classe. The type jungling > makes sense in implementations, as it always was but argument passing > and validation have been a source of pain since very long. I could > imagine one exception with the "numeric" type, which could accept > anything and got converted to integer/numeric values, like "1235ab" or > other weird things. Personal opinion of a nonvoter, just for the record :) The fact that roughly everybody in the strict-and-validation camp in the recent discussions, adds in a different view on "with the exception of", very very strongly suggests that the strict-and-validation POV is wrong wrong wrong. On the one hand, because calling code will become sprinkled with casts on function calls to coerce the arguments to conform to the strict interpretation. And on the other hand, because validation needs, for all practical purposes, are far more finegrained than any half-a-dozen-type scheme. So, I'm 100% in the cast camp, i.e. interpret scalar type annotation of function arguments as syntactic sugar for explicit casts at the beginning of the function. best regards Patrick
Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
hi Andrea, On Sun, Jul 13, 2014 at 3:57 AM, Andrea Faulds wrote: > Good evening, > > PHP’s type hinting system is rather incomplete as it does not support > scalars, only arrays, callables and objects. In 2012, Anthony Ferrara created > an RFC which proposed type hinting for scalar types (int, float, bool, string > and resource) with casting, with behaviour nearly the same as that of > zend_parse_parameters. Sadly, he later left PHP internals and withdrew his > RFCs. > > Since I am very much in favour of scalar type hints, I’ve updated the patch > to master and made some minor improvements, and I am re-opening the RFC with > the intent to try and get it into PHP 5.7. The patch is mostly there. It > needs some more tests and there are some edge cases I need to deal with, but > it otherwise works, and I expect I can finish fixing it up very soon. > > The RFC is here: https://wiki.php.net/rfc/scalar_type_hinting_with_cast > > A pull request is here: https://github.com/php/php-src/pull/717 > > I’m hoping I can get this into PHP 5.7. I think scalar type hinting would be > a valuable addition to PHP’s existing type hinting system. very nice work, thanks! Some comments or wishes. I know these points have been discussed already in the other threads but I still think it is worth posting that here and (re) consider it. To me argument types handling should match what we already do for classes, strict handling. I asked many users at various conferences or large companies using PHP and this is also what they wish. Indeed I am not saying that all users wish that (who am I to say that? :) but I feel like there is a large majority expecting this behavior. The argument saying that it is not the PHP way is somehow incorrect here, given that we already do that for classe. The type jungling makes sense in implementations, as it always was but argument passing and validation have been a source of pain since very long. I could imagine one exception with the "numeric" type, which could accept anything and got converted to integer/numeric values, like "1235ab" or other weird things. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Deprecating GD functions imagettftext/bbox
hi, On Tue, Jul 22, 2014 at 9:01 PM, Lonny Kapelushnik wrote: > Morning, > > I propose deprecating two GD functions: imagettftext and imagettfbbox. > > The reasons I would like to deprecate them are: > 1. Their functionality is a subset of imagefttext and imageftbbox > 2. The imagettf* functions have the same requirements as the imageft* > functions > 3. The imagettf* functions parameters are compatible with the imageft* > functions parameters > > As far as I can tell the original reason for having both functions was > because PHP LIBGD is a custom implementation of LIBGD that had additional > functionality from the actual LIBGD. While this is still the case it seems > that now the required functions (gdImageStringFT and gdImageStringFTEx) > exist in both libraries. > > The only difference between imagettf* and imageft* functions is the > imagettf* functions do not provide the optional ‘extrainfo’ parameter > > The only step to migrate from the imagettf* functions to imageft* functions > is to change the function names from ‘imagettf*’ to ‘imageft*' > > I would like to create a timeline to deprecate and remove the imagettf* > functions. Providing a timeline will allow for: > 1. Clarity for which PHP functions to use going forward > 2. Ability to plan a migration to the new PHP functions > 3. Clarity for which PHP functions to improve in php-src > 4. Ability to clean up some of the GD code in php-src > > I will hold off on proposing an actual timeline for now. > > I can implement any coding changes needed. > > Please let me know the general thoughts to deprecating these functions. If > the reception is positive I would like to create an RFC to discuss this in > full and come up with a timeline. It is on my list to mark them as deprecated in the documentation. Also I am not sure it is worth the disagreement for the users to add notices or even to remove them as they both use the same underlying code. Basically there is no gain for us to actually remove them but yet another notice for the users. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
