FAQ
Morning Chaps,

  I have opened the vote on anonymous classes, following on from
conversations had in IRC, we have the option to postpone this until 5.7 ...

Cheers

Search Discussions

  • Pierre Joye at Oct 7, 2013 at 7:08 am
    hi!
    On Mon, Oct 7, 2013 at 8:29 AM, Joe Watkins wrote:
    Morning Chaps,

    I have opened the vote on anonymous classes, following on from
    conversations had in IRC, we have the option to postpone this until 5.7 ...
    Can you move it to the voting phase section please?


    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Pierre Joye at Oct 7, 2013 at 7:10 am
    hi,
    On Mon, Oct 7, 2013 at 8:29 AM, Joe Watkins wrote:
    Morning Chaps,

    I have opened the vote on anonymous classes, following on from
    conversations had in IRC, we have the option to postpone this until 5.7 ...
    Also I do not always follow IRC discussions. What is the reasoning
    behind post pone this feature to an hypothetical 5.7? Or why not 5.6?

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Joe Watkins at Oct 7, 2013 at 7:38 am

    On 10/07/2013 08:09 AM, Pierre Joye wrote:
    hi,
    On Mon, Oct 7, 2013 at 8:29 AM, Joe Watkins wrote:
    Morning Chaps,

    I have opened the vote on anonymous classes, following on from
    conversations had in IRC, we have the option to postpone this until 5.7 ...
    Also I do not always follow IRC discussions. What is the reasoning
    behind post pone this feature to an hypothetical 5.7? Or why not 5.6?

    Cheers,
    Morning Pierre,

      5.6 remains an option ...

      I brought it up in IRC the other day and someone, I forget who, but
    recognized them at the time, said they'd rather see it in 5.7, then a
    few people joined in the discussion and I couldn't really argue with
    their reasoning.

      The main point was that even a simple patch can have a destabilizing
    effect, and we've already merged several "simple" patches into 5.6.

      I think it's a bit early to call time on 5.6 features, and I think
    features like this require quite some time for adoption and should be
    out as quickly as possible ...

      I don't really know what is best ...

      Moved to voting bit ..

      Sorry mike, thanks for posting link :)

    Cheers
  • Pierre Joye at Oct 7, 2013 at 7:48 am

    On Mon, Oct 7, 2013 at 9:38 AM, Joe Watkins wrote:

    5.6 remains an option ...

    I brought it up in IRC the other day and someone, I forget who, but
    recognized them at the time, said they'd rather see it in 5.7, then a few
    people joined in the discussion and I couldn't really argue with their
    reasoning.

    The main point was that even a simple patch can have a destabilizing
    effect, and we've already merged several "simple" patches into 5.6.

    I think it's a bit early to call time on 5.6 features,
    It is not and we should begin soon to branch 5.6 and go with the
    milestones planing to get it out in June.
    and I think
    features like this require quite some time for adoption and should be out as
    quickly as possible ...
    I agree.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Joe Watkins at Oct 7, 2013 at 8:15 am

    On 10/07/2013 08:48 AM, Pierre Joye wrote:
    On Mon, Oct 7, 2013 at 9:38 AM, Joe Watkins wrote:

    5.6 remains an option ...

    I brought it up in IRC the other day and someone, I forget who, but
    recognized them at the time, said they'd rather see it in 5.7, then a few
    people joined in the discussion and I couldn't really argue with their
    reasoning.

    The main point was that even a simple patch can have a destabilizing
    effect, and we've already merged several "simple" patches into 5.6.

    I think it's a bit early to call time on 5.6 features,
    It is not and we should begin soon to branch 5.6 and go with the
    milestones planing to get it out in June.
    and I think
    features like this require quite some time for adoption and should be out as
    quickly as possible ...
    I agree.

    Cheers,
    Hi Pierre,

    Re: "It is not ..."

    You seem to agree :)

    If we should do it _soon_, and not _now_, then it is a _bit_ too early
    isn't it ??

    The end of 2015 is very far away from the perspective of the PHP user;
    they are not engaged in learning what will be available in two years
    time, look at adoption rates. The anonymous classes patch is actually
    simple, I can't imagine that it will have a profound effect on the
    things around it ...

    Cheers
    Joe
  • Johannes Schlüter at Oct 7, 2013 at 11:49 am

    On Mon, 2013-10-07 at 08:38 +0100, Joe Watkins wrote:
    I brought it up in IRC the other day and someone, I forget who, but
    recognized them at the time, said they'd rather see it in 5.7, then a
    few people joined in the discussion and I couldn't really argue with
    their reasoning.
    When I brought this up I was on my current primary rant. Even small
    additions to the language have an impact on tools, best practices, ...
    which have to be explored about how to use them and how those interact
    with each other.

    To be clear: I love anonymous classes, I always wanted them when using
    FilterIterator etc. (while meanwhile generators+closures might be a
    better tool for some of those use cases) But we are moving extremely
    fast in reshaping the language making it hard for our users, of which
    many -- in my assumption -- primarily want a stable platform, to keep
    up.

    Oh and talking about "stable platform". Current bug count: 3891

    See also my previous message on that subject:
    http://news.php.net/php.internals/69093

    johannes
  • Pierre Joye at Oct 7, 2013 at 2:09 pm

    On Mon, Oct 7, 2013 at 1:49 PM, Johannes Schlüter wrote:

    Oh and talking about "stable platform". Current bug count: 3891
    And most of them are not in the language per se but in extensions or
    some totally ignored (see #65486 for what where you are in charge :).

    Now, ranting on IRC is all good and shiny. Leading new RFC
    contributors to confusion and mess up a vote is something slightly
    less shiny. If you could raise your actual points on the list next
    time, during the discussion period, then we will not lose time trying
    to figure out what happened or what led him to propose such choices.
    Thanks.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Joe Watkins at Oct 7, 2013 at 2:55 pm

    On 10/07/2013 12:49 PM, Johannes Schlüter wrote:
    On Mon, 2013-10-07 at 08:38 +0100, Joe Watkins wrote:
    I brought it up in IRC the other day and someone, I forget who, but
    recognized them at the time, said they'd rather see it in 5.7, then a
    few people joined in the discussion and I couldn't really argue with
    their reasoning.
    When I brought this up I was on my current primary rant. Even small
    additions to the language have an impact on tools, best practices, ...
    which have to be explored about how to use them and how those interact
    with each other.

    To be clear: I love anonymous classes, I always wanted them when using
    FilterIterator etc. (while meanwhile generators+closures might be a
    better tool for some of those use cases) But we are moving extremely
    fast in reshaping the language making it hard for our users, of which
    many -- in my assumption -- primarily want a stable platform, to keep
    up.

    Oh and talking about "stable platform". Current bug count: 3891

    See also my previous message on that subject:
    http://news.php.net/php.internals/69093

    johannes
    The observation that even a small patch has an impact, or can have an
    impact is valid. But then to talk about adoption time turns your
    reasoning a bit circular: adoption does take time, if we want for
    adoption to take place then the earlier a patch gets merged the better,
    regardless of the complexity of the patch.

    I did see your "rant", though it's not really a rant; perfectly valid
    observations. Still, I don't know what you hope to achieve by pointing
    out the differences between the development of C or Java, and PHP:
    progress plotted on a graph nobody would expect to see any kind of
    relationship or commonality between these languages. So while they are
    valid observations they aren't really relevant.

    The bug count is a bit shameful, some effort should obviously be spent
    on bugs ...

    Cheers
    Joe
  • Johannes Schlüter at Oct 7, 2013 at 3:30 pm

    On Mon, 2013-10-07 at 15:55 +0100, Joe Watkins wrote:

    The observation that even a small patch has an impact, or can have an
    impact is valid. But then to talk about adoption time turns your
    reasoning a bit circular: adoption does take time, if we want for
    adoption to take place then the earlier a patch gets merged the better,
    regardless of the complexity of the patch.
    The issue is not that we are adding a single patch the issue is that we
    recently change the language in a rapid pace.
    I did see your "rant", though it's not really a rant; perfectly valid
    observations. Still, I don't know what you hope to achieve by pointing
    out the differences between the development of C or Java, and PHP:
    progress plotted on a graph nobody would expect to see any kind of
    relationship or commonality between these languages. So while they are
    valid observations they aren't really relevant.
    It is the only metric I have to answer comments if the sort "oh, PHP is
    developing so slowly" while we are fast in changing the language.

    What we i.e. don't do is trying to adopt our "standard library" to new
    paradigms being introduced. Also after changing the language we don't
    really check how this impacts new languages features. Maybe generators
    have an impact on the way anonymous classes should be designed? etc. I
    guess most here look at this with a PHP 5.2/5.3 mindset, not 5.5 or at
    least 5.4.

    that all said:
    The bug count is a bit shameful, some effort should obviously be spent
    on bugs ...
    This is the actual point here: We as a community at large should imo
    focus more on fixing bugs instead of creating new ones. If we could
    spend more of the time we spend on discussing new things on actually
    fixing bugs instead it is my unproven subjective claim that we'd make
    more people happy than by any "syntax sugar".

    And again to be really clear: This is nothing directly related to this
    feature, this patch or even you, but a very general opinion/observation
    from my side based on my observations and my discussions with users
    about current state of things.

    With that: All from my side is said and I hope we can end this more
    general sub-thread and use the time better :-)

    johannes
  • Pierre Joye at Oct 7, 2013 at 4:20 pm

    On Mon, Oct 7, 2013 at 5:30 PM, Johannes Schlüter wrote:
    On Mon, 2013-10-07 at 15:55 +0100, Joe Watkins wrote:

    The observation that even a small patch has an impact, or can have an
    impact is valid. But then to talk about adoption time turns your
    reasoning a bit circular: adoption does take time, if we want for
    adoption to take place then the earlier a patch gets merged the better,
    regardless of the complexity of the patch.
    The issue is not that we are adding a single patch the issue is that we
    recently change the language in a rapid pace.
    I did see your "rant", though it's not really a rant; perfectly valid
    observations. Still, I don't know what you hope to achieve by pointing
    out the differences between the development of C or Java, and PHP:
    progress plotted on a graph nobody would expect to see any kind of
    relationship or commonality between these languages. So while they are
    valid observations they aren't really relevant.
    It is the only metric I have to answer comments if the sort "oh, PHP is
    developing so slowly" while we are fast in changing the language.
    We do not change the language. We improve it. Changing the language
    implies that one has to change his existing code or application to get
    them run on a new release. That's not the case between 5.4 and 5.5,
    and should not be between 5.5 and 5.6.

    However we are not fast or slow, we only fill gaps with other modern languages.
    What we i.e. don't do is trying to adopt our "standard library" to new
    paradigms being introduced. Also after changing the language we don't
    really check how this impacts new languages features. Maybe generators
    have an impact on the way anonymous classes should be designed? etc. I
    guess most here look at this with a PHP 5.2/5.3 mindset, not 5.5 or at
    least 5.4.
    That's a good point and that's why we have RFCs. We have to review the
    impacts of a new feature, discuss the possible issues (design, BC,
    etc.).

    that all said:
    The bug count is a bit shameful, some effort should obviously be spent
    on bugs ...
    This is the actual point here: We as a community at large should imo
    focus more on fixing bugs instead of creating new ones.
    A project focusing only on fixing bugs and does not implement new
    features is a dead project, they only don't know it yet.
    If we could
    spend more of the time we spend on discussing new things on actually
    fixing bugs instead it is my unproven subjective claim that we'd make
    more people happy than by any "syntax sugar".
    I think it is somehow not correct to say that.

    My team participates in a lot of discussions, we test all RFCs, before
    they end in the voting phase, continuously. We fix bugs, tons of bugs.
    We report bugs too. And many other developers do so as well. On the
    other hand some developers discuss/argue a lot while not fixing bugs
    at all nor developing new features. There are also developers being
    better at developing new features rather than doing QA. That's all
    good and we should try to figure out a way to work better together
    instead of blocking each other.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Michael Wallner at Oct 7, 2013 at 7:11 am

    On 7 October 2013 08:29, Joe Watkins wrote:
    Morning Chaps,

    I have opened the vote on anonymous classes, following on from
    conversations had in IRC, we have the option to postpone this until 5.7 ...
    You could have done us laziers a favor and add the link:
    https://wiki.php.net/rfc/anonymous_classes#voting :)


    --
    Regards,
    Mike
  • Nikita Popov at Oct 7, 2013 at 9:46 am

    On Mon, Oct 7, 2013 at 8:29 AM, Joe Watkins wrote:

    Morning Chaps,

    I have opened the vote on anonymous classes, following on from
    conversations had in IRC, we have the option to postpone this until 5.7 ...

    Cheers
    The "Include in PHP 5.7" voting option, does this mean that we already now
    decide to include it in 5.7 or does it mean that we wish to reevaluate the
    feature during the 5.7 cycle?

    Nikita
  • Joe Watkins at Oct 7, 2013 at 9:49 am

    On 10/07/2013 10:46 AM, Nikita Popov wrote:
    On Mon, Oct 7, 2013 at 8:29 AM, Joe Watkins wrote:

    Morning Chaps,

    I have opened the vote on anonymous classes, following on from
    conversations had in IRC, we have the option to postpone this until 5.7 ...

    Cheers
    The "Include in PHP 5.7" voting option, does this mean that we already now
    decide to include it in 5.7 or does it mean that we wish to reevaluate the
    feature during the 5.7 cycle?

    Nikita
    I'm not sure, whatever seems appropriate ... if we're going to say that
    it's too late for this to go in 5.6, then it can't be too early to
    decide it can go in 5.7 can it ??

    Cheers
    Joe
  • Joe Watkins at Oct 7, 2013 at 10:13 am

    On 10/07/2013 10:49 AM, Joe Watkins wrote:
    On 10/07/2013 10:46 AM, Nikita Popov wrote:
    On Mon, Oct 7, 2013 at 8:29 AM, Joe Watkins wrote:

    Morning Chaps,

    I have opened the vote on anonymous classes, following on from
    conversations had in IRC, we have the option to postpone this until
    5.7 ...

    Cheers
    The "Include in PHP 5.7" voting option, does this mean that we already
    now
    decide to include it in 5.7 or does it mean that we wish to reevaluate
    the
    feature during the 5.7 cycle?

    Nikita
    I'm not sure, whatever seems appropriate ... if we're going to say that
    it's too late for this to go in 5.6, then it can't be too early to
    decide it can go in 5.7 can it ??

    Cheers
    Joe
    Morning Chaps,

      On the advice of many, I have restarted the vote, sorry for the
    inconvenience/confusion ...

    Cheers
    Joe
  • Peter Cowburn at Oct 7, 2013 at 10:21 am

    On 7 October 2013 11:13, Joe Watkins wrote:
    Morning Chaps,

    On the advice of many, I have restarted the vote, sorry for the
    inconvenience/confusion ...

    https://wiki.php.net/rfc/anonymous_classes#voting (re-link, for the lazy)

    The voting options changed from choosing a version ("5.6", "5.7") or
    rejecting… too a much simpler, yes/no for sticking this into master. Which
    branch/release the feature makes it into is something to be decided down
    the line (ultimately, by the RMs).

    Cheers
    Joe
  • Joe Watkins at Oct 9, 2013 at 7:58 am

    On 10/07/2013 11:20 AM, Peter Cowburn wrote:
    On 7 October 2013 11:13, Joe Watkins wrote:

    Morning Chaps,

    On the advice of many, I have restarted the vote, sorry for the
    inconvenience/confusion ...

    https://wiki.php.net/rfc/anonymous_classes#voting (re-link, for the lazy)

    The voting options changed from choosing a version ("5.6", "5.7") or
    rejecting… too a much simpler, yes/no for sticking this into master. Which
    branch/release the feature makes it into is something to be decided down
    the line (ultimately, by the RMs).

    Cheers
    Joe
    Morning All,

      To anyone who has voted or will vote no; if you have voted no but is
    something that could be done to the patch to change your mind, please do
    speak up :)

      If you voted/will vote no and there's nothing that can change your
    mind, I'd still be interested in hearing the reasoning ...

      This is a pretty quiet vote ... as this is the first RFC I have put
    forward, I'd like a bit more feedback so I can avoid the avoidable in
    the future ...

    Cheers
    Joe
  • Paul Dragoonis at Oct 9, 2013 at 11:14 am
    Hi Joe,

    Thanks for your hard work on anonymous classes.

    I voted no because I feel it's just adding more and more ways to achieve
    similar results and the syntax is just more sugary fluff to allow people to
    do things the wrong way.

    We've had a lot of new features in recent versions, i.e: traits, so I
    believe this isn't something PHP needs right now and PHP needs to focus on
    bug fixing and solidifying what we have right now.

    Thanks,
    Paul

    On Wed, Oct 9, 2013 at 8:58 AM, Joe Watkins wrote:
    On 10/07/2013 11:20 AM, Peter Cowburn wrote:
    On 7 October 2013 11:13, Joe Watkins wrote:


    Morning Chaps,

    On the advice of many, I have restarted the vote, sorry for the
    inconvenience/confusion ...

    https://wiki.php.net/rfc/**anonymous_classes#voting<https://wiki.php.net/rfc/anonymous_classes#voting>(re-link, for the lazy)

    The voting options changed from choosing a version ("5.6", "5.7") or
    rejecting… too a much simpler, yes/no for sticking this into master.
    Which
    branch/release the feature makes it into is something to be decided down
    the line (ultimately, by the RMs).


    Cheers
    Joe

    Morning All,
    To anyone who has voted or will vote no; if you have voted no but
    is something that could be done to the patch to change your mind, please do
    speak up :)

    If you voted/will vote no and there's nothing that can change your
    mind, I'd still be interested in hearing the reasoning ...

    This is a pretty quiet vote ... as this is the first RFC I have
    put forward, I'd like a bit more feedback so I can avoid the avoidable in
    the future ...


    Cheers
    Joe

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Ferenc Kovacs at Oct 9, 2013 at 11:22 am

    On Wed, Oct 9, 2013 at 9:58 AM, Joe Watkins wrote:
    On 10/07/2013 11:20 AM, Peter Cowburn wrote:
    On 7 October 2013 11:13, Joe Watkins wrote:


    Morning Chaps,

    On the advice of many, I have restarted the vote, sorry for the
    inconvenience/confusion ...

    https://wiki.php.net/rfc/**anonymous_classes#voting<https://wiki.php.net/rfc/anonymous_classes#voting>(re-link, for the lazy)

    The voting options changed from choosing a version ("5.6", "5.7") or
    rejecting… too a much simpler, yes/no for sticking this into master.
    Which
    branch/release the feature makes it into is something to be decided down
    the line (ultimately, by the RMs).


    Cheers
    Joe

    Morning All,
    To anyone who has voted or will vote no; if you have voted no but
    is something that could be done to the patch to change your mind, please do
    speak up :)

    If you voted/will vote no and there's nothing that can change your
    mind, I'd still be interested in hearing the reasoning ...

    This is a pretty quiet vote ... as this is the first RFC I have
    put forward, I'd like a bit more feedback so I can avoid the avoidable in
    the future ...


    Cheers
    Joe

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    I have voted no based on the lack of support for
    serialization/unserialization, and I think that we agreed that without
    somehow naming the class, we can't support that, and having a name would
    defeat the purpose of this feature.

    I'm looking forward to nested classes though.

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Joe Watkins at Oct 9, 2013 at 11:39 am

    On 10/09/2013 12:22 PM, Ferenc Kovacs wrote:
    On Wed, Oct 9, 2013 at 9:58 AM, Joe Watkins wrote:
    On 10/07/2013 11:20 AM, Peter Cowburn wrote:
    On 7 October 2013 11:13, Joe Watkins wrote:


    Morning Chaps,

    On the advice of many, I have restarted the vote, sorry for the
    inconvenience/confusion ...

    https://wiki.php.net/rfc/**anonymous_classes#voting<https://wiki.php.net/rfc/anonymous_classes#voting>(re-link, for the lazy)

    The voting options changed from choosing a version ("5.6", "5.7") or
    rejecting… too a much simpler, yes/no for sticking this into master.
    Which
    branch/release the feature makes it into is something to be decided down
    the line (ultimately, by the RMs).


    Cheers
    Joe

    Morning All,
    To anyone who has voted or will vote no; if you have voted no but
    is something that could be done to the patch to change your mind, please do
    speak up :)

    If you voted/will vote no and there's nothing that can change your
    mind, I'd still be interested in hearing the reasoning ...

    This is a pretty quiet vote ... as this is the first RFC I have
    put forward, I'd like a bit more feedback so I can avoid the avoidable in
    the future ...


    Cheers
    Joe

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    I have voted no based on the lack of support for
    serialization/unserialization, and I think that we agreed that without
    somehow naming the class, we can't support that, and having a name would
    defeat the purpose of this feature.

    I'm looking forward to nested classes though.
    Tyrael,

      As mentioned in the RFC, there's nothing stopping you from serializing
    an anonymous class.
      Anonymous classes are named, they _have_ to be; they are named after
    the codepath (so file/function/class) prefixed with namespace where they
    are used ... so in fact there's nothing wrong with the vast majority of
    applications using serialization of anonymous class objects.

      Nested classes is more complicated than anonymous ones, if this doesn't
    get in on a vote I don't see nested classes getting in either; if the
    reason people are voting no is really that "we need to concentrate on
    bugs", then what is really the point in preparing another RFC before 5.6
    is out in the wild ...

      I hear the syntax sugar thing ... but it's starting to wear a bin thin,
    it's a phrase thrown around without much justification or thought:
    Almost everything you add at the Zend level which requires some kind of
    syntax (so, pretty much everything) can be described as syntactic sugar.
    It is only a parser modification, but that should only make it more
    appealing, we aren't asking anything new of Zend ...

      In any case, I appreciate the input :)

    Cheers
    Joe
  • Ferenc Kovacs at Oct 9, 2013 at 12:18 pm

    I have voted no based on the lack of support for
    serialization/unserialization, and I think that we agreed that without
    somehow naming the class, we can't support that, and having a name would
    defeat the purpose of this feature.

    I'm looking forward to nested classes though.

    Tyrael,
    As mentioned in the RFC, there's nothing stopping you from
    serializing an anonymous class.
    Anonymous classes are named, they _have_ to be; they are named
    after the codepath (so file/function/class) prefixed with namespace where
    they are used ... so in fact there's nothing wrong with the vast majority
    of applications using serialization of anonymous class objects.
    yeah, and you can't autoload that, and if you move the instanitation of an
    anonymous class the generated internal classname will be different.
    and that is all fine for handling the instance in that specific request,
    but makes any attempt to persist and restore really fragile.
    I also think that anonymous classes and functions should be similar in this
    sense, and currently we don't allow the serialization of Closure
    instances(but we do allow the serialization of create_function(), and I do
    understand why is that, but it is not what most people would guess), which
    is a bit sucky, because you have to remember, that closures work the same
    way as any other callable, except that it can't be serialized (but it can
    be json_encoded and it will result in an empty object).
    I think that having such restrictions, when something almost works the way
    one would expect is wrong.

    Nested classes is more complicated than anonymous ones, if this
    doesn't get in on a vote I don't see nested classes getting in either; if
    the reason people are voting no is really that "we need to concentrate on
    bugs", then what is really the point in preparing another RFC before 5.6 is
    out in the wild ...
    anonymous classes and nested classes have a bit different usecases, hence
    supporter base, I think you shouldn't guess on the result for that based on
    the feedback on anonymous classes.

    I hear the syntax sugar thing ... but it's starting to wear a bin
    thin, it's a phrase thrown around without much justification or thought:
    Almost everything you add at the Zend level which requires some kind of
    syntax (so, pretty much everything) can be described as syntactic sugar. It
    is only a parser modification, but that should only make it more appealing,
    we aren't asking anything new of Zend ...
    I didn't bring up this point, but I do agree that having changes in the
    ZE/parser should be done with a good reason, and simply because it could
    have a much wider impact area and less people familiar with fixing those
    kind of bugs.

    In any case, I appreciate the input :)
    and we appreciate your work on improving php. _o_

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Joe Watkins at Oct 9, 2013 at 12:29 pm
    Just quick note ... If you autoload a class which in turn unserializes an
    object of an anonymous class autoloading will not be invoked for the
    anonymous class ... It is compiled when you load the super / outer class
    ... Am out and about on phone ... I think these kinds of issues can be
    explained / resolved ...
    On 9 Oct 2013 13:18, "Ferenc Kovacs" wrote:


    I have voted no based on the lack of support for
    serialization/unserialization, and I think that we agreed that without
    somehow naming the class, we can't support that, and having a name would
    defeat the purpose of this feature.

    I'm looking forward to nested classes though.

    Tyrael,
    As mentioned in the RFC, there's nothing stopping you from
    serializing an anonymous class.
    Anonymous classes are named, they _have_ to be; they are named
    after the codepath (so file/function/class) prefixed with namespace where
    they are used ... so in fact there's nothing wrong with the vast majority
    of applications using serialization of anonymous class objects.
    yeah, and you can't autoload that, and if you move the instanitation of an
    anonymous class the generated internal classname will be different.
    and that is all fine for handling the instance in that specific request,
    but makes any attempt to persist and restore really fragile.
    I also think that anonymous classes and functions should be similar in
    this sense, and currently we don't allow the serialization of Closure
    instances(but we do allow the serialization of create_function(), and I do
    understand why is that, but it is not what most people would guess), which
    is a bit sucky, because you have to remember, that closures work the same
    way as any other callable, except that it can't be serialized (but it can
    be json_encoded and it will result in an empty object).
    I think that having such restrictions, when something almost works the way
    one would expect is wrong.

    Nested classes is more complicated than anonymous ones, if this
    doesn't get in on a vote I don't see nested classes getting in either; if
    the reason people are voting no is really that "we need to concentrate on
    bugs", then what is really the point in preparing another RFC before 5.6 is
    out in the wild ...
    anonymous classes and nested classes have a bit different usecases, hence
    supporter base, I think you shouldn't guess on the result for that based on
    the feedback on anonymous classes.

    I hear the syntax sugar thing ... but it's starting to wear a bin
    thin, it's a phrase thrown around without much justification or thought:
    Almost everything you add at the Zend level which requires some kind of
    syntax (so, pretty much everything) can be described as syntactic sugar. It
    is only a parser modification, but that should only make it more appealing,
    we aren't asking anything new of Zend ...
    I didn't bring up this point, but I do agree that having changes in the
    ZE/parser should be done with a good reason, and simply because it could
    have a much wider impact area and less people familiar with fixing those
    kind of bugs.

    In any case, I appreciate the input :)
    and we appreciate your work on improving php. _o_

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu
  • Matthew Leverton at Oct 9, 2013 at 11:29 am

    On Wed, Oct 9, 2013 at 2:58 AM, Joe Watkins wrote:
    This is a pretty quiet vote ... as this is the first RFC I have put
    forward, I'd like a bit more feedback so I can avoid the avoidable in the
    future ...
    I'm not a voter, but I'd lean toward 'no' on this because a) I really
    dislike the syntax and b) it didn't seem to play 100% nicely with core
    PHP features (e.g. serialization). However, I do think there's a place
    for such a feature in PHP though (just take a look at SplHeap).

    I wish RFC voters had to leave a brief comment (even if from a canned
    list) on the voting page when voting 'no' because it would add a lot
    more transparency to the process. I know a lot of people do comment
    somewhere and I trust that they vote responsibly, but it's hard to put
    it all together at the end.

    --
    Matthew Leverton
  • David Soria Parra at Oct 12, 2013 at 7:10 pm

    Matthew Leverton schrieb:
    On Wed, Oct 9, 2013 at 2:58 AM, Joe Watkins wrote:

    I wish RFC voters had to leave a brief comment (even if from a canned
    list) on the voting page when voting 'no' because it would add a lot
    more transparency to the process. I know a lot of people do comment
    somewhere and I trust that they vote responsibly, but it's hard to put
    it all together at the end.
    It's a wiki page, all voters have edit rights. We can simply introduce a
    "vote reasoning" part.
  • Sebastian Bergmann at Oct 7, 2013 at 2:40 pm

    On 10/06/2013 11:29 PM, Joe Watkins wrote:
    I have opened the vote on anonymous classes, following on from
    conversations had in IRC, we have the option to postpone this until 5.7
      The option to postpone for PHP 5.7 implies that there is already a
      deadline for PHP 5.6. Is there?
  • Pierre Joye at Oct 7, 2013 at 3:03 pm

    On Mon, Oct 7, 2013 at 4:40 PM, Sebastian Bergmann wrote:
    On 10/06/2013 11:29 PM, Joe Watkins wrote:
    I have opened the vote on anonymous classes, following on from
    conversations had in IRC, we have the option to postpone this until 5.7
    The option to postpone for PHP 5.7 implies that there is already a
    deadline for PHP 5.6. Is there?
    There is a deadline for the next release yes, ~June 2014.

    Cheers,
    --
    Pierre

    @pierrejoye | | http://www.libgd.org

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedOct 7, '13 at 6:29a
activeOct 12, '13 at 7:10p
posts26
users12
websitephp.net

People

Translate

site design / logo © 2022 Grokbase