FAQ
All,



As we’re getting closer to release 5.6.0, and given the very high level of
interest in phpng, I think it’s time for us to provide some clarity
regarding what happens post 5.6.0.



Dmitry and I wrote an RFC proposing that we merge phpng into master and
turn it into the basis of the next major version of PHP (name TBD).



The RFC is available at https://wiki.php.net/rfc/phpng



Some supporting links available down below.



Comments welcome!



Zeev







Performance evaluation & evolution of phpng:

https://wiki.php.net/phpng#performance_evaluation



phpng internals:

https://wiki.php.net/phpng-int



Benchmarking PHPNG (benchmark results of phpng vs 5.4, 5.5, 5.6 and hhvm):

http://zsuraski.blogspot.co.il/2014/07/benchmarking-phpng.html

Search Discussions

  • Zeev Suraski at Jul 24, 2014 at 10:51 pm

    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
  • Pierre Joye at Jul 25, 2014 at 2:24 am

    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
  • Tjerk Meesters at Jul 24, 2014 at 10:51 pm
    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 <pierre.php@gmail.com>
    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
  • Yasuo Ohgaki at Jul 25, 2014 at 3:48 am
    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
    yohgaki@ohgaki.net
  • Kris Craig at Jul 25, 2014 at 4:28 am

    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
  • Pierre Joye at Jul 25, 2014 at 4:53 am

    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
  • Zeev Suraski at Jul 25, 2014 at 7:51 am
    On Fri, Jul 25, 2014 at 7: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.

    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?
    The text I put there is exactly what I think about the subject of required
    majority. 50%+1 is enough for a change that does not effect end users in
    any meaningful way, but I'll be happier if it received a 2/3 majority to
    leave any doubts away.

    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 the person who wrote that text in the Voting RFC, I can tell you with
    absolute certainty that you are 100% wrong in your interpretation, as I've
    said numerous times in the past.
    A feature that affects the *language* itself is not a feature that affects
    the *language implementation*.
    Generally speaking, now that we have a Specification project, the spirit of
    the Voting RFC is that changes to the Language Specification would require
    2/3 majority, while all other changes would not. This is also not 100%
    accurate since there are some elements of the language behavior that aren't
    covered by the spec (e.g.superglobal availability and behavior) - but
    replacing the implementation with a compatible one absolutely does *not* fall
    within the realm of "features that affect the language".

    If you recall the 64-bit discussion several months ago, when I was (back
    then) on the opposing side, I clearly said to people who said this requires
    a 2/3 majority that it's very debatable - because while it does have some
    end user impact that changes the language behavior, it's mostly an
    implementation issue, which as such requires a simple majority. So I'm
    both consistent, and not reinterpreting the rules to fit my needs.

      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.
    I updated the section to be fully technical and removed my wish of heart to
    get a 2/3 majority. Although I'd still very much like to get > 2/3, it's
    not required.

    Zeev
  • Pierre Joye at Jul 25, 2014 at 8:11 am

    On Fri, Jul 25, 2014 at 9:51 AM, Zeev Suraski wrote:
    On Fri, Jul 25, 2014 at 7: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.

    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?
    The text I put there is exactly what I think about the subject of required
    majority. 50%+1 is enough for a change that does not effect end users in
    any meaningful way, but I'll be happier if it received a 2/3 majority to
    leave any doubts away.
    It affects users, it is a total rewamp of the engine, it requires 2/3.
    I fail to understand to see yet another attempt to discard simple RFC
    rules.
    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 the person who wrote that text in the Voting RFC, I can tell you with
    absolute certainty that you are 100% wrong in your interpretation, as I've
    said numerous times in the past.
    A feature that affects the *language* itself is not a feature that affects
    the *language implementation*.
    It affects both, there is no point to argue.

    I updated the section to be fully technical and removed my wish of heart to
    get a 2/3 majority. Although I'd still very much like to get > 2/3, it's
    not required.
    It is.


    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Ferenc Kovacs at Jul 25, 2014 at 8:27 am
    2014.07.25. 9:52, "Zeev Suraski" <zeev@zend.com> ezt írta:
    On Fri, Jul 25, 2014 at 7: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.

    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?
    The text I put there is exactly what I think about the subject of required
    majority. 50%+1 is enough for a change that does not effect end users in
    any meaningful way, but I'll be happier if it received a 2/3 majority to
    leave any doubts away.

    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 the person who wrote that text in the Voting RFC, I can tell you with
    absolute certainty that you are 100% wrong in your interpretation, as I've
    said numerous times in the past.
    A feature that affects the *language* itself is not a feature that affects
    the *language implementation*.
    hi,

    I'm not really following the phpng development that closely, but afaik it
    does have some userland impact (the change for using the same argument name
    in a function signature multiple times and the change in func_get_args()
    comes into mind).

    We also discussed before that major breakage in the extension "api" would
    also warrant a 2/3 vote, but it seems that you disagree with that.

    My last argument is, that given that we allow anybody with a php.net
    account to vote on Zend Engine changes, we are always safer with the 2/3
    vote.
    That way the worst thing that can happen is something not getting into, but
    the authors can try again (after fixing the cause of the no votes), but
    with simple majority it would be rather easy to force something into the
    language, even if all of the active Zend maintainers vote no because it is
    a horrible design decision or has a crappy implementation.

    just my 2 cents ofc.
  • Kris Craig at Jul 26, 2014 at 9:41 pm

    On Fri, Jul 25, 2014 at 12:51 AM, Zeev Suraski wrote:

    On Fri, Jul 25, 2014 at 7: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.

    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?
    The text I put there is exactly what I think about the subject of required
    majority. 50%+1 is enough for a change that does not effect end users in
    any meaningful way, but I'll be happier if it received a 2/3 majority to
    leave any doubts away.

    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 the person who wrote that text in the Voting RFC, I can tell you with
    absolute certainty that you are 100% wrong in your interpretation, as I've
    said numerous times in the past.
    A feature that affects the *language* itself is not a feature that
    affects the *language implementation*.
    That may be what you meant, Zeev, but that's not what you wrote. As Jonny
    already pointed out, what you intended isn't relevant if it doesn't match
    the final wording you actually put in there.

    The Voting RFC doesn't say "language implementation". It says "language".
      That means, if it affects the language, it requires 2/3. Period. If you
    wanted it to have a more narrow definition, then why didn't you put it in
    there? It's just not making any sense to me. You might want to consider
    putting an amendment to the Voting RFC to a vote to clarify that language,
    but as it stands right now, any feature that affects the language itself--
    regardless of userland impact-- requires a 2/3 vote. Saying, "Well, that's
    not exactly what I meant," after the fact just isn't a convincing argument
    for me.

    Generally speaking, now that we have a Specification project, the spirit
    of the Voting RFC is that changes to the Language Specification would
    require 2/3 majority, while all other changes would not. This is also not
    100% accurate since there are some elements of the language behavior that
    aren't covered by the spec (e.g.superglobal availability and behavior) -
    Again, I'd strongly suggest you propose new language for the Voting RFC to
    reflect these statements, because none of that is apparent in the current
    wording.

    but replacing the implementation with a compatible one absolutely does
    *not* fall within the realm of "features that affect the language".
    I disagree. Whether or not the new stuff is "compatible", it does directly
    affect the language. The PHPNG RFC itself even acknowledges that it
    affects the language. Furthermore, as far as the "spirit" of the Voting
    RFC is concerned, I seriously doubt it would be in the spirit of it to
    merge a massive overhaul of the codebase that will affect virtually all
    development with just a simple majority. It could be (and has been) argued
    that this will inevitably lead to userland changes. But again, whether it
    affects userland or not is completely irrelevant. The Voting RFC says--
    whether you "meant" it to or not, it does say-- that 2/3 is required if it
    affects the language, period. It does not contain any exceptions for
    lessened impact on userland.

    If you recall the 64-bit discussion several months ago, when I was (back
    then) on the opposing side, I clearly said to people who said this requires
    a 2/3 majority that it's very debatable - because while it does have some
    end user impact that changes the language behavior, it's mostly an
    implementation issue, which as such requires a simple majority. So I'm
    both consistent, and not reinterpreting the rules to fit my needs.
    Fair enough. You have been consistent on this so I don't think anyone can
    reasonably accuse you of just trying to twist this to suit your needs.

    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.
    I updated the section to be fully technical and removed my wish of heart
    to get a 2/3 majority. Although I'd still very much like to get > 2/3,
    it's not required.
    According to the current Voting RFC rules, this RFC must require a 2/3
    majority because it affects the language. Ugh this is exactly why an
    adjudication process is needed, which we don't have that I'm aware of. We
    don't have a "supreme court" to decide this. But it's clear that we need
    some way to adjudicate this in a manner that would be acceptable to both
    sides. The alternative is for you and everyone else to keep repeating
    their arguments back and forth. Then, if your RFC gets a simple majority
    but not 2/3, we can watch as you try to carry out the merge and Pierre and
    whoever else try to block and revert it. I don't think that's an ideal
    outcome but that is where we're headed. Even if you believe you're
    justified in using this interpretation that expands the stated meaning, I
    really think you should go with the 2/3 vote in order to avoid sparking
    what could be a very ugly conflict.

    Please take the high road on this, then later we can revisit the Voting RFC
    and discuss collectively how to make it clearer for situations like this.

    --Kris
  • Zeev Suraski at Jul 26, 2014 at 10:16 pm
    Kris,



    I’ll make it short.



    EVERY RFC affects the language in *some* way – be it its features,
    positioning, perception, performance, implementation, testability, you name
    it. Each and every one, or we wouldn’t be discussing it on php.net’s
    internals@ mailing list. So I’m afraid I’m not going to use *your*
    interpretation for what the Voting RFC means (which in effect is either 2/3
    majority for every RFC) – but rather, what I *know* is the meaning, and
    what is clearly the spirit of the RFC. Spirit I say? Here’s what I mean:



    *“**Given that changes to languages (as opposed to changes to apps or even
    frameworks) are for the most part irreversible”*



    Implementation improvements such as PHPNG are not irreversible. New
    features or changed features are. This deals with language features, that
    once we publish, we cannot take back as people already start using them.



    *“the purpose of the vote is to ensure that there's strong support for the
    proposed feature.”*



    Is PHPNG a feature? No, it’s not. It’s improvements & performance
    optimizations at the implementation level. Those who have been following
    my involvement on internals@ over the years know my position about both
    feature creep and downwards compatibility, and I’m absolutely certain that
    it was clear to them – most if not all – what the meaning here was. That’s
    100.0% irrelevant to PHPNG.


    FYI, I don’t intend to ping pong with you about it. I’ve said what I had
    to say about that topic.



    Zeev
  • Andrea Faulds at Jul 26, 2014 at 10:32 pm

    On 26 Jul 2014, at 23:16, Zeev Suraski wrote:

    *“**Given that changes to languages (as opposed to changes to apps or even
    frameworks) are for the most part irreversible”*



    Implementation improvements such as PHPNG are not irreversible. New
    features or changed features are. This deals with language features, that
    once we publish, we cannot take back as people already start using them.



    *“the purpose of the vote is to ensure that there's strong support for the
    proposed feature.”*



    Is PHPNG a feature? No, it’s not. It’s improvements & performance
    optimizations at the implementation level. Those who have been following
    my involvement on internals@ over the years know my position about both
    feature creep and downwards compatibility, and I’m absolutely certain that
    it was clear to them – most if not all – what the meaning here was. That’s
    100.0% irrelevant to PHPNG.
    For what it’s worth, I’d completely agree with Zeev here. phpng is really just an implementation deal, it doesn’t need a 2/3 vote, controversial or no.
    --
    Andrea Faulds
    http://ajf.me/
  • Benjamin Eberlei at Jul 26, 2014 at 10:49 pm
    In that case tthe voting RFC should be improved. The sentence about 1/2 vs
    2/3 votes is really ambiguous.
    Not fixing it will always lead to discussions over and over again.

    On Sun, Jul 27, 2014 at 12:32 AM, Andrea Faulds wrote:

    On 26 Jul 2014, at 23:16, Zeev Suraski wrote:

    *“**Given that changes to languages (as opposed to changes to apps or even
    frameworks) are for the most part irreversible”*



    Implementation improvements such as PHPNG are not irreversible. New
    features or changed features are. This deals with language features, that
    once we publish, we cannot take back as people already start using them.



    *“the purpose of the vote is to ensure that there's strong support for the
    proposed feature.”*



    Is PHPNG a feature? No, it’s not. It’s improvements & performance
    optimizations at the implementation level. Those who have been following
    my involvement on internals@ over the years know my position about both
    feature creep and downwards compatibility, and I’m absolutely certain that
    it was clear to them – most if not all – what the meaning here was. That’s
    100.0% irrelevant to PHPNG.
    For what it’s worth, I’d completely agree with Zeev here. phpng is really
    just an implementation deal, it doesn’t need a 2/3 vote, controversial or
    no.
    --
    Andrea Faulds
    http://ajf.me/





    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Matteo Beccati at Jul 26, 2014 at 11:08 pm

    On 27/07/2014 00:32, Andrea Faulds wrote:
    Is PHPNG a feature? No, it’s not. It’s improvements & performance
    optimizations at the implementation level. Those who have been following
    my involvement on internals@ over the years know my position about both
    feature creep and downwards compatibility, and I’m absolutely certain that
    it was clear to them – most if not all – what the meaning here was. That’s
    100.0% irrelevant to PHPNG.
    For what it’s worth, I’d completely agree with Zeev here. phpng is really just an implementation deal, it doesn’t need a 2/3 vote, controversial or no.
    I agree about the meaning and the fact that phpng is implementation.

    However if there is some userland BC break, then it should effectively
    be 2/3, shouldn't it? How about the "Incompatibilities (made on purpose
    and are not going to be fixed)"?


    Cheers
    --
    Matteo Beccati

    Development & Consulting - http://www.beccati.com/
  • Kris Craig at Jul 27, 2014 at 12:53 am

    On Sat, Jul 26, 2014 at 3:16 PM, Zeev Suraski wrote:

    Kris,



    I’ll make it short.



    EVERY RFC affects the language in *some* way – be it its features,
    positioning, perception, performance, implementation, testability, you name
    it.
    I believe that argument is specious. The RFC says, "....a feature
    affecting the language *itself*" (emphasis mine). A feature that affects
    performance need not necessarily affect the language itself. For example,
    an RFC to add an APXS configuration option to the configure script would
    have no impact on the language itself, even though it technically involves
    a modified implementation and testing scenario. And affecting people's
    "perception" of PHP most certainly does not constitute a feature that
    affects the language itself, unless you're making a quantum theory argument
    wherein the mere act of observing something alters its state.

    Finally, here's an example from your RFC of how it *directly* impacts the
    language itself:
    PHPNG doesn't keep original values of arguments passed to user functions,
    so func_get_arg() and func_get_args() will return current value of argument
    instead of the actually passed. The following code is going to be affected
    “function foo($x) { $x = 2; return func_get_arg(0);} var_dump(foo(1));”
    Function parameters with duplicate name are not allowed anymore.
    Definitions like “function foo($x,$x) {}” will lead to compile time error
    “Redefinition of parameter”

    So even IF you want to reduce the scope of the 2/3 requirement to language
    impacts in userland only, your RFC *still* falls under that requirement
    because it directly affects the language itself in userland, as described
    above. I would again invite you to reconsider your position on this and
    avoid a protracted fight on this that would only serve to split the
    community.

    --Kris
  • Andrea Faulds at Jul 27, 2014 at 12:57 am

    On 27 Jul 2014, at 01:53, Kris Craig wrote:

    so func_get_arg() and func_get_args() will return current value of argument
    instead of the actually passed. The following code is going to be affected
    “function foo($x) { $x = 2; return func_get_arg(0);} var_dump(foo(1));”
    Those are to be considered functions, not language features.
    Function parameters with duplicate name are not allowed anymore.
    Definitions like “function foo($x,$x) {}” will lead to compile time error
    “Redefinition of parameter”
    While that’s *technically* a language change, such code doesn’t work properly anyway.

    --
    Andrea Faulds
    http://ajf.me/
  • Michael Wallner at Jul 27, 2014 at 6:10 am

    On 27 07 2014, at 02:53, Kris Craig wrote:

    So even IF you want to reduce the scope of the 2/3 requirement to language
    impacts in userland only, your RFC *still* falls under that requirement
    because it directly affects the language itself in userland, as described
    above. I would again invite you to reconsider your position on this and
    avoid a protracted fight on this that would only serve to split the
    community.

    I’m actually not sure why we even have to vote on PHP-NG?

    How about for the crusaders to build something comparable to put up to vote against PHP-NG?

    There isn’t? Well, then let’s go ahead. Simple.

    Rolling eyes,
    Mike


    PS: My dog wants voting rights because he feels like he’ll be affected by changes to PHP.
  • Kris Craig at Jul 27, 2014 at 6:23 am
    On Sat, Jul 26, 2014 at 11:10 PM, Michael Wallner wrote:
    On 27 07 2014, at 02:53, Kris Craig wrote:

    So even IF you want to reduce the scope of the 2/3 requirement to language
    impacts in userland only, your RFC *still* falls under that requirement
    because it directly affects the language itself in userland, as described
    above. I would again invite you to reconsider your position on this and
    avoid a protracted fight on this that would only serve to split the
    community.

    I’m actually not sure why we even have to vote on PHP-NG?

    How about for the crusaders to build something comparable to put up to
    vote against PHP-NG?

    There isn’t? Well, then let’s go ahead. Simple.
    To answer your question (sort-of), the alternative to PHP-NG is what we
    have right now. I can't speak for anyone else, of course, but I certainly
    am not opposed to PHP-NG, even though Zeev seems to think so. I just don't
    think it's ready to be merged into master yet, based on everything I've
    seen, including concerns raised by others more knowledgeable than I on this
    list. I also just want to make sure something so massive in scope isn't
    pushed through by a slim majority, especially since doing so would violate
    the Voting RFC as it's currently written and would probably lead to an ugly
    fight among those who have RW+ access.

    I actually like PHP-NG and what it strives to do. I just think its
    developers are jumping the gun and trying to force something through that
    many in the community feel is not yet ready for deployment. I honestly
    don't understand why there's such a rush and why people who are calling for
    things to slow down so that cooler heads can prevail are being demonized
    and mocked. It's not "you're either with us or you're against us." I
    don't oppose PHP-NG simply because I want to make sure all the ducks are in
    a row before it's deployed.

    Here's my question to counter yours, Michael: What's the rush?

    --Kris
  • Michael Wallner at Jul 27, 2014 at 7:16 am

    On 27 Jul 2014 08:23, "Kris Craig" wrote:
    Here's my question to counter yours, Michael: What's the rush?
    Every day php-ng is not GA, PHP is losing ground to its competitors.

    People seem to ignore this because of cosmetics.
  • Kris Craig at Jul 27, 2014 at 7:26 am
    On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner wrote:
    On 27 Jul 2014 08:23, "Kris Craig" wrote:

    Here's my question to counter yours, Michael: What's the rush?
    Every day php-ng is not GA, PHP is losing ground to its competitors.
    Umm, how? Do you have any data to support this? According to
    http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing.
      As far as our competitors are concerned, well:

    http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python


    As you can see, PHP continues to dominate with over 80% market share and no
    signs-- at least, none that I can see-- that we are "losing ground" as you
    stated.

    So again: What's the rush?

    --Kris
  • Lester Caine at Jul 27, 2014 at 7:49 am

    On 27/07/14 08:26, Kris Craig wrote:
    As you can see, PHP continues to dominate with over 80% market share and no
    signs-- at least, none that I can see-- that we are "losing ground" as you
    stated.

    So again: What's the rush?
    Especially since 75% of that are still on PHP5.3 or 5.2 ;)

    But I had forgotten the comparison has a breakdown by ranking. I made
    the unsubstantiated comment about big sites not using PHP which of cause
    this shows, but there is no reference to the alternative PHP engines?
    One question that does come too mind is "Why is python so popular with
    the bigger sites?" Is it because compiled builds are fully supported?
    Certainly if any of my own sites traffic started to take off I would be
    looking down that avenue, so while improving the speed of interpreted
    working is important, it is still stability in the language that blocks
    uptake?

    --
    Lester Caine - G8HFL
    -----------------------------
    Contact - http://lsces.co.uk/wiki/?page=contact
    L.S.Caine Electronic Services - http://lsces.co.uk
    EnquirySolve - http://enquirysolve.com/
    Model Engineers Digital Workshop - http://medw.co.uk
    Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
  • Michael Wallner at Jul 27, 2014 at 8:03 am

    On 27 Jul 2014 09:26, "Kris Craig" wrote:


    On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner wrote:

    On 27 Jul 2014 08:23, "Kris Craig" wrote:

    Here's my question to counter yours, Michael: What's the rush?
    Every day php-ng is not GA, PHP is losing ground to its competitors.
    Umm, how? Do you have any data to support this? According to
    http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing.
      As far as our competitors are concerned, well:
    http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python

    As you can see, PHP continues to dominate with over 80% market share and
    no signs-- at least, none that I can see-- that we are "losing ground" as
    you stated.
    >

    Surely it's wise to make the same wrong assumptions Microsoft did with
    Internet Explorer?
  • Kris Craig at Jul 27, 2014 at 9:44 am
    On Sun, Jul 27, 2014 at 1:03 AM, Michael Wallner wrote:
    On 27 Jul 2014 09:26, "Kris Craig" wrote:




    On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner <
    mike.php.net@gmail.com> wrote:
    On 27 Jul 2014 08:23, "Kris Craig" wrote:

    Here's my question to counter yours, Michael: What's the rush?
    Every day php-ng is not GA, PHP is losing ground to its competitors.
    Umm, how? Do you have any data to support this? According to
    http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing.
    As far as our competitors are concerned, well:
    http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python

    As you can see, PHP continues to dominate with over 80% market share and
    no signs-- at least, none that I can see-- that we are "losing ground" as
    you stated.
    Surely it's wise to make the same wrong assumptions Microsoft did with
    Internet Explorer?
    Again, where's your evidence, Michael? I provided two separate sources
    that provide data showing that PHP is *gaining* market share and continues
    to dominate over the competition, which directly contradicts the claim you
    made. Simply brushing this factual data as "wrong assumptions"-- without
    any data of your own to back-up that claim-- does not constitute a valid
    counter-argument, nor does introducing a non sequitur by comparing PHP to
    Internet Explorer.

    These aren't "assumptions", wrong or otherwise. This is data pulled from
    reliable sources. If you have separate data that calls it into question,
    then please share it with us. Otherwise, you're just making baseless and
    factually inaccurate claims about PHP to justify your argument about
    PHP-NG. As far as I can tell from the evidence available, your statement
    that "PHP is losing ground to its competitors" appears to be false. In
    fact, the exact opposite appears to be true. Again, that's not an
    assumption. That's just looking at the available data.

    --Kris
  • Michael Wallner at Jul 27, 2014 at 10:00 am
    On 27 07 2014, at 11:44, Kris Craig wrote:

    [a lot]

    Maybe because you see those as competitors, but I see HHVM and friends as current competitors, being evaluated to replace stock PHP, which is definitely not covered by any nice statistics you can currently view.

    Cheers,
    Mike
  • Kristopher at Jul 27, 2014 at 1:28 pm
    Instead of endless, useless bickering, how about everyone both for and
    against merging jump in and start helping with phpng (docs, api
    cleanup/stabilization, but fixes, etc)?

    Imagine how much more stable and ready to merge it would be if you
    concentrated the saber rattling energy towards actually accomplishing
    something.



    On Sun, Jul 27, 2014 at 6:00 AM, Michael Wallner wrote:


    On 27 07 2014, at 11:44, Kris Craig wrote:

    [a lot]

    Maybe because you see those as competitors, but I see HHVM and friends as
    current competitors, being evaluated to replace stock PHP, which is
    definitely not covered by any nice statistics you can currently view.

    Cheers,
    Mike


    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Kris Craig at Jul 28, 2014 at 12:13 am

    On Sun, Jul 27, 2014 at 3:00 AM, Michael Wallner wrote:
    On 27 07 2014, at 11:44, Kris Craig wrote:

    [a lot]

    Maybe because you see those as competitors,

    You're the one who said PHP was losing ground to its "competitors", not I.

    but I see HHVM and friends as current competitors, being evaluated to
    replace stock PHP, which is definitely not covered by any nice statistics
    you can currently view.
    So, in other words, you're basing your claim on anecdotal and purely
    hypothetical assumptions about unnamed people "evaluating" other languages
    to replace PHP. Even if your self-serving guess were true, for which there
    is no evidence that has been presented here, it still wouldn't substantiate
    your claim because evaluating alternatives to your current codebase doesn't
    mean you're going to actually switch to any of them. So either way, PHP is
    not, as you claimed, "losing ground" to anyone.

    [a lot]
    >

    I've been trying to maintain a civil discussion here, but I have to say,
    Michael, thus far you have done nothing but make immature, snyde personal
    attacks and baseless, factually inaccurate claims. You have not
    contributed anything substantive or constructive to this debate up to this
    point. From your "rolling eyes" comment where you speculated about your
    dog wanting voting rights to now, you have been very disrespectful and
    uncivil toward everyone here. I don't want to discourage anyone from
    expressing their views, but on the same token, I'm not here to feed trolls.

    This issue clearly brings out strong emotions in some people and we clearly
    disagree on certain points. That said, please make a greater effort to be
    respectful toward other people on this list, whether you agree with them or
    not. Your trolling comments have all but hijacked this thread over the
    last 17 hours and it's detracting from substantive debate that needs to
    happen.

    If you have some issue with me personally, please take it off-list. If
    you're going to post further on this thread, please try to be more
    respectful and mature in your comments.

    --Kris


    http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js
  • David Dai at Jul 28, 2014 at 2:44 am


    On 27 07 2014, at 11:44, Kris Craig (mailto:kris.craig@gmail.com)> wrote:

    [a lot]

    Maybe because you see those as competitors, but I see HHVM and friends as current competitors, being evaluated to replace stock PHP, which is definitely not covered by any nice statistics you can currently view.
    I can confirm that, wikimedia is migrating from PHP to HHVM, see: http://lists.wikimedia.org/pipermail/wikitech-l/2014-July/077690.html
    and I also have saw many friends talking about migrating from PHP to HHVM only for performance gain.
    Cheers,
    Mike


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


    Cheers,
    David Dai
  • Lester Caine at Jul 28, 2014 at 8:01 am

    On 28/07/14 03:44, David Dai wrote:
    I can confirm that, wikimedia is migrating from PHP to HHVM, see: http://lists.wikimedia.org/pipermail/wikitech-l/2014-July/077690.html
    and I also have saw many friends talking about migrating from PHP to HHVM only for performance gain.
    That perhaps brings up more questions than it answers. I've moved to
    nginx from Apache after the problems with conversion from 2.2 to 2.4 and
    found that performance was much improved, so while looking at PHP
    performance in isolation gives one result, it's the combination needed
    to create the full stack which we aught to be benchmarking?

    --
    Lester Caine - G8HFL
    -----------------------------
    Contact - http://lsces.co.uk/wiki/?page=contact
    L.S.Caine Electronic Services - http://lsces.co.uk
    EnquirySolve - http://enquirysolve.com/
    Model Engineers Digital Workshop - http://medw.co.uk
    Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
  • Yasuo Ohgaki at Jul 27, 2014 at 10:54 pm
    Hi all,
    On Sun, Jul 27, 2014 at 5:03 PM, Michael Wallner wrote:

    On 27 Jul 2014 09:26, "Kris Craig" wrote:




    On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner <
    mike.php.net@gmail.com> wrote:
    On 27 Jul 2014 08:23, "Kris Craig" wrote:

    Here's my question to counter yours, Michael: What's the rush?
    Every day php-ng is not GA, PHP is losing ground to its competitors.
    Umm, how? Do you have any data to support this? According to
    http://php.net/usage.php, as of 2012, PHP's usage is steadily increasing.
    As far as our competitors are concerned, well:
    http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python

    As you can see, PHP continues to dominate with over 80% market share and
    no signs-- at least, none that I can see-- that we are "losing ground" as
    you stated.
    Surely it's wise to make the same wrong assumptions Microsoft did with
    Internet Explorer?
    PHP is losing as a general scripting language for sure.
    JavaScript is winning in this area even if it was originated as "a web
    client scripting language".

    http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
    http://langpop.com/

    We are better to consider this situation seriously. IMHO.
    Focus on web as well as encourage general usage is what we need.
    Making PHP a choice for "new" project should be one of the most important
    objective.

    Regards,

    --
    Yasuo Ohgaki
    yohgaki@ohgaki.net
  • Kris Craig at Jul 28, 2014 at 12:18 am

    On Sun, Jul 27, 2014 at 3:54 PM, Yasuo Ohgaki wrote:

    Hi all,
    On Sun, Jul 27, 2014 at 5:03 PM, Michael Wallner wrote:

    On 27 Jul 2014 09:26, "Kris Craig" wrote:




    On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner <
    mike.php.net@gmail.com> wrote:
    On 27 Jul 2014 08:23, "Kris Craig" wrote:

    Here's my question to counter yours, Michael: What's the rush?
    Every day php-ng is not GA, PHP is losing ground to its competitors.
    Umm, how? Do you have any data to support this? According to
    http://php.net/usage.php, as of 2012, PHP's usage is steadily
    increasing. As far as our competitors are concerned, well:
    http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python

    As you can see, PHP continues to dominate with over 80% market share
    and no signs-- at least, none that I can see-- that we are "losing ground"
    as you stated.
    Surely it's wise to make the same wrong assumptions Microsoft did with
    Internet Explorer?
    PHP is losing as a general scripting language for sure.
    JavaScript is winning in this area even if it was originated as "a web
    client scripting language".

    http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
    http://langpop.com/

    We are better to consider this situation seriously. IMHO.
    Focus on web as well as encourage general usage is what we need.
    Making PHP a choice for "new" project should be one of the most important
    objective.

    Regards,

    --
    Yasuo Ohgaki
    yohgaki@ohgaki.net
    According to w3techs, JavaScript retains an extremely tiny market share in
    terms of general purpose languages:

    http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js


    It looks like the sources are all measuring different metrics. It would be
    interesting to see a closer analysis of the data and figure out which
    metrics are the most relevant to this question.

    --Kris
  • Yasuo Ohgaki at Jul 28, 2014 at 1:00 am
    Hi Kris,
    On Mon, Jul 28, 2014 at 9:18 AM, Kris Craig wrote:

    According to w3techs, JavaScript retains an extremely tiny market share in
    terms of general purpose languages:


    http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js


    It looks like the sources are all measuring different metrics. It would
    be interesting to see a closer analysis of the data and figure out which
    metrics are the most relevant to this question.
    Since we have enough market share on web apps already, why don't we focus
    more on developers? There are many awesome none web app tools that are
    developed with JavaScript because of it's popularity and developers'
    passion.

    PHP is losing popularity for sure.

    http://www.tiobe.com/index.php/content/paperinfo/tpci/PHP.html

    PHP is the worst in terms of lost popularity among top 20 languages. It
    should be
    a flag for us to adjust our strategy/view. Market share comes after
    language popularity.
    When market share has changed, it would be too late.

    Anyway, I'm willing to have phpng as master, as well as INT64 branch.
    Both are good for PHP. IMO.

    Regards,

    --
    Yasuo Ohgaki
    yohgaki@ohgaki.net
  • Mike Willbanks at Jul 28, 2014 at 1:15 am
    First off, I realize I am top posting but this thread is becoming extremely
    off-topic, unbalanced and overall ridiculous to see from the sidelines as
    someone that contributes to open source and also utilizes PHP on a daily
    basis for more than the last decade.

    Seriously, cut the shit! Everyone is bringing this to a personal and
    completely insane area; let's focus on the facts not the reactions wherever
    they might come from. Work together, no one ever agrees 100% of the time
    and continuing on that note, no one makes the best choices 100% of the
    time. Surely, as a community we will not always agree on implementations,
    timing and what is done in "secret" vs. not, what is more maintainable vs.
    what is not. Where to dedicate focus etc. Open source projects often have
    this issue. Also, no I am not taking a stance or side on what is best for
    the language. People contributing to the engine are much smarter than I in
    this level and the right choice I am certain will prevail. But have a
    reasonable conversations on facts vs. personal opinions and vendettas.

    Now, PHP is a balanced language; performance comes with a cost if it be
    memory, CPU spikes, maintainability, readability, etc. We all program
    here; this is always a trade off we need to determine, analyze and
    identify. These things have to be taken into account. Documentation is
    nice but not always necessary. Depending on what it will change and how
    much affect it will have on say extension developers and existing people
    contributing to core has to be taken into account.

    Let's get our heads straight, determine our focus for the next few years
    and start to move forward. Sure other languages gain and lose on PHP but
    this will always be the case and should not be the core focus; we're not a
    company that's on the stock market. Languages will evolve, change, become
    invented but it's not like PHP is going away in a rapid decline; sure there
    is more languages and more competition out there. For instance, I have
    been writing node.js lately and find a massive benefit in certain types of
    projects; it comes to utilizing the right tool for the right job. Surely
    you are not going to attempt to write PHP for something that should be done
    in assembly or visa-versa. Market share does affect our jobs and careers
    but there is a reason the language has been successful and will continue to
    be. A speed increase is not a magical bullet here, if that was the case
    and they wanted to use PHP they'd use HHVM or even Hack lang and change
    their usage. (Yes, there are other things there but come on, 99% of the
    time core PHP speed is not the issue.)

    Let's save the effort on this useless conversation, focus on driving
    SOMETHING forward, WHATEVER that may be and stop taking everything so damn
    personal.

    Regards,

    Mike

    On Sun, Jul 27, 2014 at 7:18 PM, Kris Craig wrote:
    On Sun, Jul 27, 2014 at 3:54 PM, Yasuo Ohgaki wrote:

    Hi all,

    On Sun, Jul 27, 2014 at 5:03 PM, Michael Wallner <mike.php.net@gmail.com

    wrote:
    On 27 Jul 2014 09:26, "Kris Craig" wrote:




    On Sun, Jul 27, 2014 at 12:16 AM, Michael Wallner <
    mike.php.net@gmail.com> wrote:
    On 27 Jul 2014 08:23, "Kris Craig" wrote:

    Here's my question to counter yours, Michael: What's the rush?
    Every day php-ng is not GA, PHP is losing ground to its competitors.
    Umm, how? Do you have any data to support this? According to
    http://php.net/usage.php, as of 2012, PHP's usage is steadily
    increasing. As far as our competitors are concerned, well:
    http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python

    As you can see, PHP continues to dominate with over 80% market share
    and no signs-- at least, none that I can see-- that we are "losing
    ground"
    as you stated.
    Surely it's wise to make the same wrong assumptions Microsoft did with
    Internet Explorer?
    PHP is losing as a general scripting language for sure.
    JavaScript is winning in this area even if it was originated as "a web
    client scripting language".

    http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
    http://langpop.com/

    We are better to consider this situation seriously. IMHO.
    Focus on web as well as encourage general usage is what we need.
    Making PHP a choice for "new" project should be one of the most important
    objective.

    Regards,

    --
    Yasuo Ohgaki
    yohgaki@ohgaki.net
    According to w3techs, JavaScript retains an extremely tiny market share in
    terms of general purpose languages:


    http://w3techs.com/technologies/comparison/pl-java,pl-php,pl-ruby,pl-python,pl-js


    It looks like the sources are all measuring different metrics. It would be
    interesting to see a closer analysis of the data and figure out which
    metrics are the most relevant to this question.

    --Kris
  • Lester Caine at Jul 27, 2014 at 7:26 am

    On 27/07/14 07:23, Kris Craig wrote:
    Here's my question to counter yours, Michael: What's the rush?
    I think that the only 'objection' I have to 'simply' merging phpng is
    that it is not just a 'single' change? This vote is all or nothing, so
    every change is bundled without a vote on particular elements. That many
    elements ARE simply improvements to the speed at which things are
    processed is not the problem here, and it may well be that the changes
    that do affect BC have a practical justification, but there will not be
    a discussion on that?

    I'm currently fighting a problem due to a blanket change to a number of
    systems, which offer a vast speed improvement, but now apparently make
    it impossible to identify the location of the client machine. The change
    to VDI is a done deal but nobody on site seems to be interested in
    fixing the resulting problem :( Due diligence would have addressed the
    problem beforehand and could well have steered things a different way.

    The 'rush' with phpng is that people need to have a stable base to be
    working with, and if php-next is to be phpng, then we need to be working
    with it. If I magically found some spare time today should I be looking
    at the current code base or phpng going forward? Documentation IS
    crucial here, and documenting those changes and providing information
    where an individual change affects BC is essential, but there should be
    some mechanism to review elements that are not so clear cut? IS_BOOL
    object container against IS_TRUE and IS_FALSE new values is probably not
    a good example, but it is a change that I don't currently see full
    rational behind ... if I create a bool container I don't know which
    value it is ...

    We do not want to complicate things by voting on each element, but it's
    the simple fact that so many elements have been re-engineered without
    the normal process that is causing irritation, so some agreement that if
    questions are raised about an element then it WILL get a proper
    discussion and if justified get reverted? I think that this is part of
    the debate on 2/3rds or 50-50 ... there are elements which would
    normally be a 2/3rds decision? So there should be an agreement that
    these can be reviewed again later?

    --
    Lester Caine - G8HFL
    -----------------------------
    Contact - http://lsces.co.uk/wiki/?page=contact
    L.S.Caine Electronic Services - http://lsces.co.uk
    EnquirySolve - http://enquirysolve.com/
    Model Engineers Digital Workshop - http://medw.co.uk
    Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
  • Pierre Joye at Jul 27, 2014 at 6:57 am

    On Sun, Jul 27, 2014 at 8:10 AM, Michael Wallner wrote:
    On 27 07 2014, at 02:53, Kris Craig wrote:

    So even IF you want to reduce the scope of the 2/3 requirement to language
    impacts in userland only, your RFC *still* falls under that requirement
    because it directly affects the language itself in userland, as described
    above. I would again invite you to reconsider your position on this and
    avoid a protracted fight on this that would only serve to split the
    community.

    I’m actually not sure why we even have to vote on PHP-NG?
    As it is surely a rhetoric question, let leave it, ok?
    How about for the crusaders to build something comparable to put up to vote against PHP-NG?

    There isn’t? Well, then let’s go ahead. Simple.

    Rolling eyes,
    Mike


    PS: My dog wants voting rights because he feels like he’ll be affected by changes to PHP.
    This kind of post surely brings us a huge step forward.


    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Dmitry Stogov at Jul 25, 2014 at 7:22 am
    We didn't care about versions while it was a separate branch.

    Changing to ZEND_ENGINE_3 makes full sense from my point of view.

    Thanks. Dmitry.

    On Fri, Jul 25, 2014 at 7:47 AM, 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!
    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
    yohgaki@ohgaki.net
  • Zeev Suraski at Jul 25, 2014 at 7:55 am
    Maybe we should wait to see if PHP 7 gets chosen and jump to
    ZEND_ENGINE_4? J

    Another option would be to simply align the version number with that of
    PHP. The separate version number dates back to 1999 where we thought we
    may put this language engine into projects other than PHP, but I think it’s
    safe to say that if we didn’t get around to it until now, it’s probably not
    going to happen in the future…



    BTW, the only reason it’s 2.7 is because the PHP version there is presently
    5.7.

    Zeev



    *From:* Dmitry Stogov
    *Sent:* Friday, July 25, 2014 10:23 AM
    *To:* Yasuo Ohgaki
    *Cc:* Zeev Suraski; PHP internals
    *Subject:* Re: [PHP-DEV] RFC: Move phpng to master



    We didn't care about versions while it was a separate branch.

    Changing to ZEND_ENGINE_3 makes full sense from my point of view.

    Thanks. Dmitry.



    On Fri, Jul 25, 2014 at 7:47 AM, 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!
    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
    yohgaki@ohgaki.net
  • Jonny Stirling at Jul 25, 2014 at 8:28 am
    Hi Zeev,

    Now we're into arguing semantics of the Voting RFC. Whether you meant
    something else when you wrote that is now irrelevant, it's what is written
    that is the rule, not somebodies individual interpretation surely? "In any
    meaning full way" are your words, not what the accepted RFC states.

    From what's been said previously, the changes in NG are strictly
    implementation changes, i.e. syntax etc remains the same throughout. That's
    great, and would require a 50%+1 for vote as far as I can see.

    However.

    If there are /any/ changes to what end-users would see, that is by
    definition a change in the language, no matter how small (or
    "meaningless"), you are into 2/3 majority territory.

    So, can those who have worked on it confirm with a simple yes / no, are
    there changes (right now) that may affect users. Second, if the answer is
    "no", is there somebody that can review and confirm that this is the case
    that hasn't worked on NG preferably (not because of trust, just because
    it's a large changeset which makes it easy to miss stuff and a fresh pair
    of eyes is good).

    Now. If yes, 2/3 majority is required. It's as simple as that. If no, then
    I would suggest starting the review to confirm. I would hope that the
    remaining time in the 2 weeks would be enough to accomplish a review, but
    somebody correct me if they think otherwise, so the vote start / end should
    hopefully be unaffected beyond vote requirements.

    Cheers.
    Jonny.

Related Discussions

People

Translate

site design / logo © 2018 Grokbase